On Friday, 19 December 2014 at 17:14:57 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 19 December 2014 at 16:59:54 UTC, Tobias Pankrath
wrote:
How would that improve the development process? Which problems
that we currently face does that solve and why? I'm not trying
to troll here.
1. You can hit a stable release for a particular application
area one by one: batch programming, server programming,
realtime programming. That could increase commercial uptake
because you hit the first stable (supported) release earlier.
2. You can defer decisions so that they happen in the right
order, and still let people work on a solution 3 releases ahead
know when their work will be evaluated.
3. You can assign different people with different expertise to
coordinate a specific development area (like GC improvments).
4. You can make sure that design-problems that are interlinked
are treated at the same time so you don't have to go "oh no,
that won't work, because we added Y in another release".
5. You can break down the problems into smaller problems and
line up milestones and dependencies.
6. You can defer all discussions that are truly breaking to a
working-group focusing on a breaking 3.0 release.
Some decent suggestions for a company that has a certain game
plan, but mostly useless for an open source project where every
contributor has their own priorities. The core team can only
work on what they think is important and evaluate whether they
want others' features or the quality of their pulls, whenever
those are provided. Think bazaar, not cathedral.
Now, you're right that the core team can do a better job of
laying out their current priorities and of having an actual
roadmap of where they'd like the project to go, but they can't
really do anything to enforce this herd of cats to listen to them.
