blob: aeb18d237602261dc31ab0430b3dcf0bac006de1 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
## 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)
([demo](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
|
