# How does the Discourse project work?
**URL:** https://meta.discourse.org/t/how-does-the-discourse-project-work/19059
**Category:** Site feedback
**Created:** [August 19, 2014, 6:51pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059 "2014-08-19T18:51:07Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@downey](https://meta.discourse.org/u/downey)
#### Post date: [August 19, 2014, 6:51pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/1 "2014-08-19T18:51:07Z")
As more and more free and open source software people become aware of the Discourse project, they’ll surely be interested in contributing in different ways.
One of the major items of interest in open source projects is what Karl Fogel in his book _[Producing Open Source Software](http://producingoss.com/)_`*` calls, “[Social and Political Infrastructure](http://producingoss.com/en/social-infrastructure.html)”. I realize many of these questions may not yet be answerable, and may certainly change over time, but I thought I’d ask them anyway in an unordered list to see if there’s any current thinking about how the project will evolve.
- How do decisions get made within the project?
- How does work get delegated?
- Is there one or more path for volunteers to become “leaders” with some type of accountability or responsibility?
- How does a product “roadmap” evolve and become clear, and a release get planned?
I don’t think there are any “right” or “wrong” answers to these questions, but many people will be looking for (implicit or explicit) answers to them to determine if the project is a good fit for their time and efforts. Anyway, just curious what people had to think about these questions, if anything at all. 🙂
`*` _This is a really good (free) book for anyone new to open source projects. It’s a little bit dated, but the author is in the midst of writing a second edition updated for more modern development tools & paradigms. Many of the overall themes still are valuable, though._
---
### Author:  [@Azareal](https://meta.discourse.org/u/Azareal)
#### Post date: [August 19, 2014, 6:54pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/2 "2014-08-19T18:54:01Z")
> [@downey](#):
>
> How do decisions get made within the project?
Jeff’s decision is final is the general idea. If someone from the team likes a specific decision then, it will probably happen. The problem with councils is that you get in a situation where it’s endless talk and no decision making.
---
### Author:  [@downey](https://meta.discourse.org/u/downey)
#### Post date: [August 19, 2014, 6:58pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/3 "2014-08-19T18:58:15Z")
> [@Azareal](#):
>
> Jeff’s decision is final is the general idea.
This is a component of a completely valid model of governance, usually called something like “benevolent dictator”. One generally hopes that the dictator is indeed benevolent, will always make decisions in the best interest of the project, and veto things only when necessary. 😄
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [August 19, 2014, 7:55pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/4 "2014-08-19T19:55:59Z")
I would not say “Jeff’s decision is final” is the model. Generally speaking, this is the model:
> **[Complaint-Driven Development](https://blog.codinghorror.com/complaint-driven-development/)**
>
> If I haven’t blogged much in the last year, it’s because we’ve been busy building that civilized discourse construction kit thing I talked about.
>
> (Yes, that’s actually the name of the company. This is what happens when you put me in charge of naming...
That is amortized across:
1. How many different Discourse instances are complaining / asking about this?
2. How many of these Discourse instances are paying customers, either ours or someone else’s?
3. What is the community composition of those Discourse instances? Large, small, specialist, generalist, cranky (I hate change), friendly (we love change)?
4. How strongly does the team feel this would help many (or all) other Discourse instances?
5. How in tune with the “Discourse philosophy” is this feature? Example: downvoting / next page buttons, very much not in tune; optional anonymous posting / export personal posts, in tune.
6. How strongly does the Discourse team personally like/want/need this feature?
This is ranked from strongest (#1) to weakest (#5+), so the more we see the higher numbers the more that particular thing is prioritized. **This assumes the people discussing have regular visibility into multiple Discourse instances with different audiences, 5 to 10 of them ideally, but even 2 or 3 is good.**
In the case where it’s kind of a UI or design thing where there’s no way to have a solution that can satisfy everyone, my philosophy is:
1. Do the simple / clean thing whenever possible
2. Gather basic feedback
3. Try it for a while (live with it)
4. Adjust it over time based on feedback from living with it
After a point, I do think you want to avoid having too much discussion and Just Try Something, and I’m fine with taking the role of the person who decides to arbitrarily move forward with a contentious decision. But this is limited to stuff where there isn’t any kind of real consensus, or significant disagreement among the minority.
---
### Author:  [@erlend\_sh](https://meta.discourse.org/u/erlend_sh)
#### Post date: [August 19, 2014, 8:22pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/5 "2014-08-19T20:22:37Z")
As for:
> [@downey](#):
>
> Is there one or more path for volunteers to become “leaders” with some type of accountability or responsibility?
Judging by how @zogstrip, @riking and @techAPJ all came to be part of the team through voluntary code contributions and community involvement, I’d say the Discourse project already has an excellent culture of [promoting from within](http://www.forbes.com/sites/susanadams/2012/04/05/why-promoting-from-within-usually-beats-hiring-from-outside/), as any healthy open source project should.
The _path_ is **do work that benefits the product & community**.
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [September 17, 2014, 5:30pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/6 "2014-09-17T17:30:15Z")
I have taken the liberty to consolidate some quotes from various threads I’ve seen over the past few days that seem to fall under this general topic.
Overall I’ve been happy with the community and the process to date.
[Jeff’s post above](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/4) is so far the answer worth referencing with regards to the current modus operandi.
However, it does seem like the community is starting to go through some post-v1.0 growing pains for a little while as new people join the community as users, participants on meta and contributors.
I think some people are now airing frustrations they were holding back in the run up to the release.
> [@haiku](#):
>
> The process is harder and more frustrating than it needs to be due to no clear demarcation between “Team stuff” and “everyone else stuff”.
> [@erlend\_sh](#):
>
> The big questions on my mind are:
>
> Where is my input most wanted right now?
> What features are likely to arrive in the next, or the following, stable release?
> [@mcwumbly](#):
>
> I think it’d be good to follow up each release with a short post that combines the release notes (or a link to them) with what your asking for here in some loose form:
>
> 1. Here’s what we shipped in this release
> 2. Here’s what’s on the top of our list now
> 3. Here’s where help or input from the community is most wanted
> [@Add link to commit on GitHub when closing a fixed bug/added feature](https://meta.discourse.org/t/add-link-to-commit-on-github-when-closing-a-fixed-bug-added-feature/19224/1):
>
> When archiving a topic on Meta for closing out a bug/feature I think it would be helpful if we linked to the actual commit message on GitHub.
> [@cpradio](#):
>
> As an aside, this is the sort of stuff I had hoped would quit happening after hitting 1.0. You are stable now, making UI changes out of the blue seems dangerous, especially when unannounced, no discussion, what-so-ever.
> [@BhaelOchon](#):
>
> I don’t think the team need to stop making changes by any means, but the changes that are made should be well-considered and deliberate and purposeful.
It’s certainly worth considering how the process can evolve and be more explicitly communicated going forward, but this is a process in of itself.
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [September 17, 2014, 5:39pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/7 "2014-09-17T17:39:43Z")
> [@mcwumbly](#):
>
> It’s certainly worth considering how the process can evolve and be more explicitly communicated going forward, but this is a process in of itself.
Agreed. I don’t want myself to come off as “overly frustrated”, but maybe “disappointed”. I thought (and made a slight assumption) that UI changes wouldn’t just drastically happen overnight again as they did going up to v1.
I know they seem minor, but when you have a lot of members and these things now change, you are left with a lot of questions you can’t answer (because you weren’t part of the discussion, especially in a complaint driven development setup).
---
### Author:  [@downey](https://meta.discourse.org/u/downey)
#### Post date: [September 17, 2014, 8:12pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/8 "2014-09-17T20:12:56Z")
I have a feeling that a non-trivial portion of changes & strategy are being discussed, debated, and decided in the non-public Slack® chat room, or other private venues, rather than here on meta or on the [#discourse IRC channel](https://meta.discourse.org/t/a-new-irc-channel/2235).
As a data point, many or most open source projects have policies that all decisions are made publicly, and many open source contributors & users will presume that’s the way things happen. (e.g., Apache has always been famous for their saying “if it didn’t happen on the mailing list, it didn’t happen”.)
---
### Author:  [@probus](https://meta.discourse.org/u/probus)
#### Post date: [September 18, 2014, 12:22pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/9 "2014-09-18T12:22:18Z")
After following this project for about a year now, I’m in some ways quite disappointed with how this has turned out. There has been good stuff as well, but from my point of view, which is UX, the project is lacking focus big time. Against my better judgement I’ll try to explain, again:
**1. There is no documentation on design**
When I first looked at the design I saw a lot of things that could be improved and some questionable design choices. I tried to find out where those came from and found nothing. There is no documentation on the design at all. You can try to follow some old forum discussions but thats 99% arbitrary small design changes made on a whim and 1% weird analogies (“this is like walking into a room”). How could I contribute, when I don’t know the original problems the designers tried to solve? I don’t know how they ended up with this compromise or what was considered. What were the decisions based on?
**2. Complaint driven design is only for the official developers**
What about the complaint driven process, you ask? Well, I haven’t seen the complaints. I have only seen how they were interpreted. There is no database on complaints that i could take a look at. Where I could see what complaints lead to what design decisions, what are the current open issues and what has been ignored. Are _my_ complaints being recorded somewhere?
**3. There is no way to officially challenge the design**
Now, I could try to come up with other solutions on my own. Take I guess about why things are the way they are. I could gather my own research and try to come up with suggestions. But the problem then becomes, there is no process to evaluate my work. I can’t be sure that it’s even considered. The way decisions seem to be made, there is a big chance that it just gets ignored or misunderstood. Without documentation on the current solution, its impossible to challenge it. And worse, you always have to start from scratch.
I could continue. I just don’t believe it will make a difference. Good design is not something you just come up with. It’s not rocket science either. It’s 90% basic ground work. Research, problem framing and solving. And that 90% of the work is either skipped or not communicated to us. @codinhorror thinks this is how every piece of software in the world is and is supposed to be. I say you need a designer in the team.
---
### Author:  [@lukelarris](https://meta.discourse.org/u/lukelarris)
#### Post date: [September 18, 2014, 12:34pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/10 "2014-09-18T12:34:10Z")
I really haven’t had an issue with UX on Discourse sites, I think they have put a lot of thought into it and I really enjoy using Discourse-powered forums. The only possible UX issue I have is how slow Discourse is on the initial page load.
I think it’s easy to misconstrue Discourse’s development method as Jeff-centered development, especially if you follow his replies on some feature threads, he does come off sometimes as a dictator with long logical posts rather than another developer. But I do think the Discourse team is definitely doing the best they can to make decisions as a team and Jeff is just the most vocal about those decisions.
---
### Author:  [@downey](https://meta.discourse.org/u/downey)
#### Post date: [September 18, 2014, 12:53pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/11 "2014-09-18T12:53:51Z")
> [@probus](#):
>
> There has been good stuff as well, but from my point of view, which is UX, the project is lacking focus big time.
FWIW, most open source projects have very little rigor and/or effort on UI/UX design. Part of that is because developers tend to not like it, and part of it is that designers aren’t really used to working in the type of collaborative environments that open source projects usually have.
---
### Author:  [@eviltrout](https://meta.discourse.org/u/eviltrout)
#### Post date: [September 18, 2014, 2:56pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/12 "2014-09-18T14:56:42Z")
> [@cpradio](#):
>
> that UI changes wouldn’t just drastically happen overnight again as they did going up to v1.
Are you following `tests-passed` though? We need some freedom to experiment between stable releases, and we definitely need a place to try things out.
If you are following stable you’ll only see changes after many weeks, after we’ve tried them out on meta, debated them and decided they’re worth keeping.
Having said that, it seems there definitely is an interest in how we do things at Discourse and it has been largely kept in the dark. I’ll bring it up at our meeting Tomorrow.
---
### Author:  [@BhaelOchon](https://meta.discourse.org/u/BhaelOchon)
#### Post date: [September 18, 2014, 3:02pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/13 "2014-09-18T15:02:31Z")
> [@probus](#):
>
> How could I contribute, when I don’t know the original problems the designers tried to solve?
I think _the_ original problem is that there were no designers **or UX developers**. Jeff wanted to reinvent forum software but neglected to get designers **and UX developers** involved from the get-go. That seems like a pretty egregious mistake in the modern era of software, where 80% of a product isn’t its features but its **experience**.
[Edited for clarity and to combat willful obtuseness.]
---
### Author:  [@eviltrout](https://meta.discourse.org/u/eviltrout)
#### Post date: [September 18, 2014, 3:10pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/14 "2014-09-18T15:10:43Z")
> [@BhaelOchon](#):
>
> I think the original problem is that there were no designers.
This isn’t true. We’ve had @awesomerobot on contract forever now and before that we had a couple of other designers. Kris has made the site much more functional and has fixed our CSS quite a lot.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [September 18, 2014, 3:13pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/15 "2014-09-18T15:13:15Z")
> [@probus](#):
>
> There is no way to officially challenge the design
I very strongly object to this. It is not the case and I have plenty of examples.
For example the “split brain activity column”, “reply glyph on mobile” etc etc.
The general way to “challenge the design” is to create a meta topic or reply to a meta topic with a strong argument about why a change is important. Ideally with more data points than “I don’t like it” or “it is wrong”
---
### Author:  [@eviltrout](https://meta.discourse.org/u/eviltrout)
#### Post date: [September 18, 2014, 3:15pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/16 "2014-09-18T15:15:09Z")
I strongly agree with your strong objection.
Also, I keep suggesting people make plugins to show how a design could work, but I haven’t seen many people do it. It would go a long way to convince us to integrate something into core if we have a working demo and other people seem to be installing it.
---
### Author:  [@downey](https://meta.discourse.org/u/downey)
#### Post date: [September 18, 2014, 3:17pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/17 "2014-09-18T15:17:01Z")
> [@eviltrout](#):
>
> Also, I keep suggesting people make plugins to show how a design could work, but I haven’t seen many people do it.
Keep in mind that creating a plugin is more of a developer task. It’s not an activity that **most typical designers** are capable of doing, or at least not one that most designers normally are accustomed to doing in their normal workflow to solicit feedback.
There are of course “[unicorns](http://www.forbes.com/sites/quora/2013/06/27/the-myth-of-the-myth-of-the-unicorn-designer/)” out there, but they’re pretty rare, especially in open source projects.
---
### Author:  [@downey](https://meta.discourse.org/u/downey)
#### Post date: [September 18, 2014, 3:20pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/18 "2014-09-18T15:20:15Z")
> [@sam](#):
>
> The general way to “challenge the design” is to create a meta topic or reply to a meta topic with a strong argument about why a change is important.
I agree, I’ve seen this done many times. However, what isn’t clear to us “regulars” ( 😛 ) is whether or not the decisions about those design ideas are being made in public or elsewhere. Sometimes it does appear that it’s the latter.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [September 18, 2014, 3:20pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/19 "2014-09-18T15:20:50Z")
Completely untrue. We had a designer at launch, this is mentioned in the launch blog post:
> Also, a huge shout out to Matt Grantham of HeroPixel and Ryan Mudryk for the beautiful default design you see here at Discourse, and on every Discourse forum out of the box. I’ll elaborate on our design process in much more detail in a future post.
And of course we’ve been working with another amazing designer, @awesomerobot for quite a while now too, maybe a year and a half.
As far as UI/UX, you can read hundreds of entries on my blog at [http://blog.codinghorror.com](http://blog.codinghorror.com) about the topic, where I document my research and sources.
Another example of decisions being questioned (here on meta) and overridden is the request to have lost password show users if that particular email or username has an account rather than generically saying “if that username or email exists, we will send a password reset email to it”. There was a lot of discussion around that and we took some convincing, we strongly opposed it at the start.
Many, many other examples I could cite.
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [September 18, 2014, 3:44pm UTC](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059/20 "2014-09-18T15:44:15Z")
I think this is more of an issue about communication, and how different groups interact:
- core team
- paying customers
- non-paying customers (those running their own instance)
- meta community
Sometimes it feels like conversations, even constructive ones about features, break down with an undercurrent of an ‘Us vs them’ mentality.
Some of that is probably inevitable, given the nature of the project.
There have been plenty of examples where UI/UX discussions take place before changes are made, whether driven by the community or by the core team. The community never makes changes unannounced though. Only the core team is in a position to do that.
It seems the things that cause a flare up these days are changes that are made without any prior warning.
There is a big spectrum here from
← “just make changes and see how people react”----- to ----- “debate each minor change before its made”. →
It’s probably more dangerous to be too far to the right, IMHO.
But that’s where the different branches come into play (stable / tests-passed). Maybe people riding on the edge just have to expect that minor unannounced changes _are_ the beginning of a discussion.
Regardless, I think its worth considering how the process can be improved or clarified.
It may help to maintain some document based on @codinghorror’s post above that can be referenced, maintained, and updated when necessary.
Something to point back to when people raise these concerns that says “this is how we do it”
[ ](https://www.youtube.com/watch?v=0hiUuL5uTKc)
[Next page](https://meta.discourse.org/t/how-does-the-discourse-project-work/19059.md?page=2)