Just to reorient ourselves: the reason why I wanted to go with rails
because I don’t want to write the entire stack myself – there should be
pieces that already exist (like an events & calendar system) that we can
just plug in.
I’m not married to rails, but I want to see if we can do that with
rails before we explore other options. So in this case, I’m prioritizing
“getting it done” over having cool tech
s/rails/django/g if we decide to go with Django instead.
Of course, we can reimplement this stuff in a “fun” way after we get it
working. I’ve just been a part of too many “let’s do boring activity X
in fun technology Y” projects that never got finished because X is
still boring, even if you’re doing X in Haskell. So I think we should
take the pragmatic approach here.
So, before we move forward discussing these technologies, let’s really
hammer out what our goals are for the site.
I’ve made a wiki page for it here:
We should still discuss things on Discourse, but we should use the wiki
to keep track of what we decide on.
I think it’s fine to use gitit for tasks and stuff. Wikipedia
organizes far more complicated efforts than ours, entirely on wiki
Okay, let’s start using Gitit for organizing tasks and stuff.
Unless we want to keep signups private, I think it’s ok to use the
wiki for signups.
I think signups needs to be private because we still need to collect
emails. Otherwise, the wiki would work for that, too.
guys you have to check this out: http://lug.ncsu.edu/
Impressive! We can probably use that as a base for our app. Let me ping
Sufyan about this.
I especially like how the newsfeed/blog part is integrated w/ the front
I wouldn’t mind having a “multi-stack” architecture (where the front
page is powered by django, the events page by rails, etc).
Or are there existing modules (Rails gems, etc.) that you think we’d
want to use?
That’s the idea. If we were building this ourselves, we would probably
go with el-node