summaryrefslogblamecommitdiffstats
path: root/2015/planning.md
blob: 4fe6e6fae983b79bb3a5f932f7138f61fa0c7067 (plain) (tree)




































































                                                                                                                                                                                                                                                                                                     
## The website

The goal is to get a working site up while doing as little work as possible ourselves.

### Prelude

(Copied from Discourse)

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 :P

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.

### What we need

 - An events/calendar system (a wiki page may be sufficient for this)
 - A blog/newsfeed (static blog using Discourse threads for comments could work ok)


### A possible solution

Switch to Django (from Rails) and use the web app powering
[lug.ncsu.edu](http://lug.ncsu.edu/)
([source](https://github.com/ncsulug/ncsulug-website)) as a
starting point for building our main website (the front page).

**Pros:**

The following will instantly be available to us:

- decent looking website designed for a similar cause
- blog module
- simple built-in wiki module (consistent looks)
([demp](http://lug.ncsu.edu/wiki/Home/))
- more focused code base, probably easier to hack on than the current ones
in use
- easier deploys: just Python+database+django modules vs. Ruby(main) + Haskell(wiki).  Though discourse still needs ruby and docker.

**Cons:**

- a bit of work to transfer the content of the current wiki (gitit based)
to the new Django app
- not worth it **if** only done because of one single component (e.g. wiki)
(not the case, since we'll be building our events/calendar system into the web app)
- Not clear that we really need an event/calendar app (described as a meetup.com copy on irc) given the very small number of events we'll have to track.  We can use a wiki page instead: scroll down to the upcoming events section on <https://wiki.haskell.org/Haskell> to see an example of this.

### Ongoing discussion

There's an ongoing discussion about other possibilities such as:

- Using static pages for the main website
- Using static page generators
- Using org-mode for the front page
([demo](http://emacsconf.github.io/emacsconf2015/) and
[source](http://git.emacsconf2015.org/emacsconf/emacsconf2015))

Please check out <http://discourse.emacsconf2015.org/t/reconsidering-our-stack/54>
and feel free to add them here