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* calls, “Social and Political Infrastructure”. 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.
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.
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.
I would not say “Jeff’s decision is final” is the model. Generally speaking, this is the model:
That is amortized across:
How many different Discourse instances are complaining / asking about this?
How many of these Discourse instances are paying customers, either ours or someone else’s?
What is the community composition of those Discourse instances? Large, small, specialist, generalist, cranky (I hate change), friendly (we love change)?
How strongly does the team feel this would help many (or all) other Discourse instances?
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.
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:
Do the simple / clean thing whenever possible
Gather basic feedback
Try it for a while (live with it)
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.
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, as any healthy open source project should.
The path is do work that benefits the product & community.
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 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.
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).
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.
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”.)
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.
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.
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.
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.
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.]
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.
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”
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.
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” out there, but they’re pretty rare, especially in open source projects.
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.
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 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.
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”
) 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.