On Friday, April 4, 2014, Happy Melon <happy.melon.wiki(a)gmail.com> wrote:
On 4 April 2014 00:38, Brian Wolff
<bawolff(a)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.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil