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.
Andrei
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).
