On Friday, 14 March 2014 at 01:16:57 UTC, Andrei Alexandrescu wrote:
Probably we don't want that anyway. Where I'd hope to get is a point where bounties increase participation and dynamism, and steer work toward certain issues.


From my point of view, bounties won't be super efficient as attracting newer people, now matter how much money you put in it. From my perspective (soon-to-graduate student), there's lot of people that would like to participate to an open source project, but don't have the knowledges yet. Those who have are already involved anyway.

Stepping in OSS code can feel like facing a giant behemoth, and getting familiar with a project, it's short/mid/long term goals, practices, do and don't is not easy, especially with D (a good example is the final-by-default discussion, where Dicebot pointed the schedule, while you were opposed to it, and most didn't knew about).

Most of the issues are DMD issues. I wouldn't mind some extra bucks, but I know that getting familiar with DMD and bugfixing it will be far more rewarding that the $100 I could make. It would extend my knowledges and in the same time give me some code to show to a future employer.

In addition, I also know that it will be a long time before I can solve any of the bug, as they require a lot of experience / knowledge of D.

I think what D needs, to drive contributors in, is mentors. People that are displayed as "contact points" for people that wants to get involved. Then in triage, some bugs could be marked as "Training" bugs: ie, bugs that could be easy to fix, but should not be solved by experienced contributors before a certain period of time, unless there is a real need. This way, it would left the door open for "newbie" to step in, say they are interested in fixing the bug, and get a DMD guru to point them to the right way.

I think someone mentionned that in the "Broken" thread, but D could use a documented governance model (something like a simplified Qt open governance model).

Reply via email to