> > 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?
Ways it could make things worse: *incorrect advice given (if the newbies knew what to look for in a patch, by definition i wouldnt call them a newbie). This is a real risk if we start directing inexperianced people to do code review. Patch contributors are often new people too, leading them astray has a big cost *giving people false hope that their patch will get metged and in the end making them more fet up with the entire process. If a newbie tests a patch and then says something like - this fixes the problem for me, that is mildly helpful. I worry if we start encouraging newbies to do CR from the how to become a mw hacker page, we will end up with silly comments like "-1: missing trailing ?>". > > 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). Most patches are like the former. Its relatively rare to have a patch with many versions and a couple +1's unless its actively in the process of being reviewed or pending some external event. > > 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. Sure, but its kind of an oxymoron to say, hey people who are new and unfamilar with our social and technical conventions, please asses wether this patch meets those social and technical conventions. -- Bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
