On Friday, April 4, 2014, Happy Melon happy.melon.wiki@gmail.com wrote:
On 4 April 2014 00:38, Brian Wolff <bawolff@gmail.com javascript:;> wrote:
what about directing new volunteers there, asking them to submit their
code
revisions. For a patch that has been waiting in silence for over a
year,
any feedback will be better than no feedback.
You sure about that? I would imagine that having no one look at your code for months, then having someone who doesn't have the authority to approve it nit pick it a little, followed by another couple months of waiting, to be more frustrating then no feedback at all.
No, I'm not sure. Now those changesets are buried somewhere. The hypothesis is that channeling some attention to them cannot make things worse. Perhaps the nitpicking helps to bring back the attention of the maintainers?
Maybe we can dig deeper in the metrics, and find changesets with last versions of patches waiting for a first review, a different case from, say, open changesets with many versions, many comments and some +1 (a place where a newcomer would not add much).
This is also completely the wrong way to go about open-source development. The work priorities of volunteers are the thing that you, as manager of paid staff, *can't* control, as opposed to the work priorities of paid staff, which you very much can.
Agreed, and one of the reasons for producing these metrics is to help paid developers prioritize their work taking into account the task of reviewing the contributions they receive. However...
If reviewing these old patches was in any way interesting/exciting/fulfilling, volunteers would probably already have *made* some contributions.
This would be true if such potential contributions could be easily found by new contributors. Currently they are well hidden, you really need to know where to go in order to find a Gerrit changeset welcoming feedback.
Can we define URLs to Gerrit queries to be advertized at https://www.mediawiki.org/wiki/Annoying_little_bugs ? For instance, we offer links to EASY bugs, and looking at the paths chosen by e.g. potential GSoC candidates I would say that the system kind of works.
Being occasionally tasked with uninteresting/unexciting/unfulfilling tasks that Just Need Doing is one of the things that paid developers *get *paid *for*.
Many tasks that are considered uninteresting/unexciting/unfulfilling by experienced contributors are interesting/exciting/fulfilling for new contributors. Again, the EASY bugs are a good example. Ideas to define good tasks for newcomers in our review queues are welcome.