Hey all, I want to write a longer response to this and will elaborate on some points later… but I’ve got a full-time job on top of my work for Discourse…
The community feedback has really been integral the the changes and improvements made. As far as an “official design challenge”… make a post here. Create mock-ups, provide reasoning, draw something on a napkin. I can promise you that we’ll look at it. It might not be today, it might be a week from now.
A lot of the changes over the past year with Discourse have been driven by posts here. There’s been a lot of productive debate within threads. The fact that Discourse is being used by thousands of people every day is research and user testing — it’s more robust than a lot of research and testing that I’ve seen corporations pay agencies tens (sometimes hundreds) of thousands of dollars for.
Personally I think for minor changes this a very good strategy. If open up long discussions for every minor change it can be paralysing. Often, the more minor the change, the stronger the opinion’s are.
(^^^ @lid bug) I am not saying we should be cowboys that are only reacting to anger on the communities side. But tiny stuff is usually safe to do and then see what the reaction is.
This is true, and decisions don’t have necessarily have to be made by the general public. But they should still be kept “in the loop”. From the classic “Producing Open Source Software” by one of the fathers of open source, Karl Fogel:
Even after you’ve taken the project public, you and the other founders will often find yourselves wanting to settle difficult questions by private communications among an inner circle. This is especially true in the early days of the project, when there are so many important decisions to make, and, usually, few volunteers qualified to make them. All the obvious disadvantages of public list discussions will loom palpably in front of you: the delay inherent in email conversations, the need to leave sufficient time for consensus to form, the hassle of dealing with naive volunteers who think they understand all the issues but actually don’t (every project has these; sometimes they’re next year’s star contributors, sometimes they stay naive forever), the person who can’t understand why you only want to solve problem X when it’s obviously a subset of larger problem Y, and so on. The temptation to make decisions behind closed doors and present them as faits accomplis, or at least as the firm recommendations of a united and influential voting block, will be great indeed.
Don’t do it.
Of course, the question is where to draw the line between trivial decisions and important decisions. Nevertheless, in open source projects, it’s best if both types changes can be discussed publicly, regardless of who’s making the final decision (and how quickly).
Some things that effect the roadmap are things the public doesn’t have access too, like for instance I believe @sam mentioned that paying customers priorities have an impact on what they plan on working on next.
I’m not sure comparing this project to an apache project is really fair, to me I have always looked at it as a fusion between an open source and commercial product…because well that is how it is in reality!
So if you put your feet in their shoes you will be thinking about how a particular change will impact:
Actually most successful open source projects have commercial customers. They may be more of a “sponsor” or they may have service contracts with certain contributors, etc. It varies. It’s common for those organizations to have more impact in the project roadmap because they are bringing more resources to the project to get things done (for example, by paying people’s salaries). And just like with community-driven pull requests, he or she who bring resources to the table are generally the most likely to prevail.
So actually, Apache projects (especially the more popular ones) tend have a huge number of sponsored contributors. That is one of the main reasons why they’re so transparent. Even when large projects have commercially-funded contributors, those people still participate “out in the open” as community members. To do otherwise would make balancing all of those interests extremely difficult, if not impossible, for a project.
Going to be responding most to @probus here because this is covering a lot of the general consensus…
Personally, I don’t think it matters. Is there a reason you think the design process couldn’t work like this?
Search meta to see if the concept already exists
If not, make a simple post explaining it
People will respond and say “hey it’s great” or “hey this was already discussed here/or it’s not good because X”
Continue discussion, develop some specs/mock-ups
Step 1 or Step 3 is where someone might say “it is this way because of a weird analogy” and you can by all means challenge it. I’ve seen instances where @codinghorror or @sam or @eviltrout initially said “nope, not going to happen” and they were later swayed by examples/mock-ups/background info/etc.
Your complaints are all recorded here in meta. I’m curious (this might sound rhetorical but it’s not!)… is there an open-source platform you think handles this process better? Is the desire here more for something like a bug tracker?
It’s tough to say that the team considers every suggestion… some weeks are busier than others if there are customer needs, problems, or major milestones (v1.0) to work on… that being said, I know the team looks at a lot more posts than you might expect. I think it’s pretty cool that the team has collectively made over 10,000 replies on meta.
If you’re having a productive conversation somewhere on meta and there’s a change you think is worth considering — go ahead and bug someone about it if they haven’t already checked out the post. That’s what @ replies are for. Go ahead and bug me.
I get the impression that some people are thinking that the team intentionally ignores feedback or doesn’t value it — but it’s really important! Discourse wouldn’t be what it is today without the community. Yes, some decisions have to be dictated by leadership because this is a product that people are using now and time/work has to be allocated… but there’s next to nothing that’s absolutely set in stone.
Have to run again, but I may have some more thoughts later.
Okay, but shouldn’t the opposite be true too? If something is pre-existing shouldn’t there be a strong argument to all of a sudden get rid of it? (yes, this is in reference to the gutter links).
I feel like we are trying to fix an issue that only happens when you post a LOT of links within a topic. You then see a LOT of links in the gutter. Big whoop. That rarely happens (at least in our forum). We maybe have 1 or 2 links that go externally and it is NICE to have the arrows indicating where they are going/coming from. Without them, I have to do a lot more thinking… and that I don’t appreciate it.
I think the problem most people had in the gutter links arrow discussion is that this process has not been followed. The arrows were just removed without any discussion or notice beforehand.
That’s not a bad point… I could see how someone might think a small change like that would be a bug. What do you think an appropriate way to handle that would be? If a change is undocumented make a post about it in meta so people can discuss it?
There’s this dynamic of
A. Wanting to test a quick UI change without a lot of overhead (extensive documentation, bikesheddy discussions)
B. Communicating when those changes are made
I don’t want to turn off users with valuable feedback like @probus or others - but it’s a small team and it’s crucial to not create a bunch of extra work either.
Most open source projects discuss almost every change beforehand.
Discourse is different. Non-team-members post stuff in ‘bug’ or ‘feature’ and it get discussed.
The Discourse core team often makes changes without any discussion at all. There seems to be a lack of balance here.
In this specific case, even another team member said “I think@codinghorror removed this on purpose”
BTW Bikeshedding is a term used when trivial discussions are given an extraordinary amount of importance while the really strategic stuff doesn’t get any attention. I don’t think that bikeshedding is meant to be used to dismiss a discussion whenever someone has the opinion that a discussion is trivial.
I don’t think that bikeshedding is meant to be used to dismiss a discussion whenever someone has the opinion that a discussion is trivial.
I meant that any discussion about whether or not an arrow exists is generally subjective (and not at all complex) and there’s no precedence of this specific use case, so we could all discuss it all day and accomplish little. The only way to get actual data is to try it. Didn’t mean to make it sound dismissive.
Most open source projects discuss almost every change beforehand.
I guess my question is that if the team wants to try out removing something as trivial as an arrow… how should they go about doing it? I’m not sure I’ve ever seen a good method to document single minor iterations in a meaningful way. Is it a matter of releasing a bunch of changes at once and having extensive release notes? that has its own downsides.
I guess the biggest complaint I have is, is for being a system driven on complaint driven development, a lot of changes are made with zero complaints ever being made (at least publicly).
If you are getting private complaints, you should voice them in an anonymous way so that rest of us can chime in and tell you if we have similar complaints/concerns, but when there are absolutely zero and changes are just made haphazardly, we can only question the purpose/process used.
But that’s exactly what gives us the opportunity to complain!
Seriously, I think that people riding on the tests-passed or beta branches need to be a little more tolerant of the volatility and experimentation.
On the other side, I think a little more up front discussion about “what to expect in the next iteration” would be good.
Something like
OK, so we just released 1.0. 1.1 is ~ 6-8 weeks away. Here are some of the things we’ll be trying to accomplish for the next release:
Improvements to the invite system
Better upgrade page to handle the multiple release channels
…
And as always we’ll be trying out a number of small tweaks to the UI. Please continue to give us your feedback here on meta along the way!
Now, perhaps that is somewhat implied to many of us. But I think the community will continue to evolve so reinforcing the message of how things are being done would help to keep people on the same page.
Only if I continue to visit this forum frequently. Otherwise, I wouldn’t know it until I get hit by it.
No, that would be master. tests-passed is assumed stable, I really don’t think you want to push experimental changes there as they won’t be as easy to back out, should you get a lot of backlash.
Plus, I don’t think it really matters what branch you point to (well, unless you point to master… then good luck!). As the underlying issue remains the same: The claim is to be complaint driven development, but a lot of changes occur without any actual complaints. That makes the development process unknown/confusing. If we don’t know how things are changed/implemented, we can’t reasonably make predictions as to what may be coming down the pipeline – it continues to be a crap shoot.
Secondly, a road map would be ideal now that v1.0 was reached. What do you want to achieve by 1.1? 1.2?, 2.0? Do you have any ideas, or are you just randomly picking things from thin air?
Sorry, that wasn’t meant to be pointed at you, but rather the lack of a road map leads to uncertainty to how things get prioritized or what is expected/wanted per release. A road map of “here are the next 10 big things, 10 medium things, and 10 small things we want to accomplish by v2.0” would be great! It gives everyone a way to predict what is coming and chime in on things that may “complement” those goals. Or to start hashing ideas of how to implement said items by providing feedback of how they would utilize them in their communities.
tests-passed should be stable in that your site will continue to function, but its about as bleeding edge as it gets. If you want stable, be on stable.
From least to most stable:
master
not for deployment
tests-passed
safe to deploy, but stuff’ll be changing quickly. this is where experiments can be done “in the wild” to get real user feedback
beta
less volatile than tests-passed, more frequent updates than stable
stable
changes that have run the gauntlet of the other branches and survived the complaints for a number of weeks
Fair enough, but it is my understanding that meta runs bleeding edge, and that is their “experimental” testing location, which makes tests-passed a bit more stable in that, you shouldn’t see experiments until they read a certain stage (I have no idea if the removing of the arrow made it that far, but that is where I was “sort of” coming from).
