Michael Long wrote:
There are several ways to respond to this request. For example
- the project manager could set up a roadmap which issues should be addressed for the next release. In this approach the project manager confers the right to use development resources (time).
- the project manager could make suggestions for the next release. The community votes.
- the community makes suggestions and then votes.
- the community makes the suggestions, the developers vote.
- the developers decide themselves. (I think that's the current state).
- the developers make suggestions, the project manager has the final word.
Michael Long wrote:
- Should more attention being paid to priorities?
- Should the development direction be dictated (by the community/the project manager/or someone or somehow else)?
Here's the problem with any and all of the other approaches:
So you go and make a decision on the top priorities. Great! And you decide what to put in the next release. Great!
Now who does it, and when? Do you assign someone?
If not, how do you know it'll get done?
If yes, what if they don't have time? What if they don't want to? What if they initially agree but then don't have time or it ends up much more complicated than expected and they get annoyed by it and want to do something else instead?
If you choose a path in the middle and ask for volunteers, what if nobody volunteers? What if some people always volunteer and others never, and then those who always volunteer get annoyed and stop volunteering; or stop working on the project altogether?
And what do you do about patches from new contributors (which, by the way, take time and effort to review and commit... yet another thing that you need to find/assign/magic someone to take care of)? "Sorry, we're working on USB this month, your valid patch that fixes 20 applications won't be accepted... good luck next release"?
... and in case you think those are all theoretical excuses and if we just tried it, it might work... let's look at some practical examples:
- There was an Indiegogo campaign in 2014 that allowed people to vote for the top applications they'd like to see working. We all as a project agreed to work on the top three as a priority. 3.5 years later we have one of those three applications working (Unless It Regressed™), one somewhat working after you install an optional download package, and one somewhat working if you supply certain command line arguments... maybe... Unless They Regressed™.
- If you surveyed the devs over the last couple years about what most needs fixing in ROS, there's a good chance one of the top answers (if not _the_ top answer) you got was the memory manager. And what's happened in that time in that area? Well, a couple minor fixes, and an initial attempt by one dev to implement paging support. And that's a dev who finds time for ROS once every few months. Why so little progress? Because it's an extremely painful area to work on. It requires an understanding of the CPU/MMU's workings and data structures, along with specific Windows-internal data structures. It's hard to test, but has to match the externally visible semantics and internal behaviors of Windows, and of course is a major factor in OS stability and poses huge regression risks. So you must be in the mood for quite a challenge in order to want to be working on it at all.
- A recent Wine sync caused 3 tests to become "canceled" in testman (e.g. https://jira.reactos.org/browse/CORE-13830). Many people are aware that this greatly impacts tests: it makes them take longer (for each revision committed!), causes unrelated tests to become flaky, and of course hides regressions in those tests (because all you see is "canceled", no numbers). I personally consider this a blocker bug that has higher priority than anything else. And to take myself as an example, it took me a month to make a frustrated hackfix (https://github.com/reactos/reactos/pull/95), another to push some better (but also partially hacky) fixes, and I just fixed the last regression from those fixes today (https://jira.reactos.org/browse/CORE-14103). We're talking three months to fix a set of small, highest priority bugs.
- Jira has 135 outstanding patches listed: https://jira.reactos.org/issues/?filter=10101 -- this is after we've had numerous discussions over the last 2 years about how bad this is, decided to make it a priority to review patches, and several people have been doing regular bursts of reviews, interrupting whatever else they were working on. GitHub is making review easier, but already we have 36 open pull requests, and rising... https://github.com/reactos/reactos/pulls
- We have a dedicated developer who's been working on a new USB stack for the last couple months. We have three core devs that are familiar with USB & the existing driver stack, two of whom have not had much (if any) time for ROS over the last couple years. That leaves one (yours truly) to do the necessary code review and help find a sensible approach to integrating the new components. Of course I'm also supposed to fix locking in the PNP manager (so that VMware and a bunch of real hardware doesn't randomly crash on boot), the memory manager (for general system stability, application support, file system support) and, as reactosfanboy rightly mentions, fix regressions as soon as possible. So it's no wonder those code reviews may get no attention for weeks or months.
Having better management in ROS could certainly improve things. But that doesn't mean forcing a roadmap down people's throats (and yes, that includes a democratic vote). And a roadmap that gets completely turned around every other month because the only developer you have who knows a certain area is too busy with their day job and/or family to get any work done... is not very useful anyway.
We already have a few people (e.g. AmineKhaldi and reactosfanboy) who do management tasks in a way that (IMHO) is appropriate to this kind of project: talk to people about specific issues you think are important; file high-quality actionable tickets; draw attention to these issues and convince the right people at the right time that those things are beneficial to work on; and take into account the specific skills and interests of those people so as to get things done as efficiently as possible and without causing people to get annoyed or burned out.
... because you really WANT hobby devs (actually, also employed devs) to work on things they find interesting, and that they feel like working on. You don't exactly have any incentive to make them work on something else anyway. And if you did, they might just quit on you instead, because their hobby stopped being fun. So your choice becomes: they work on things you may find irrelevant, or they work on nothing at all. That's not a hard one.