Dnia 2015-10-11, o godz. 13:02:50 Manuel Rüger <mr...@gentoo.org> napisał(a):
> On 11.10.2015 10:29, Brendan Horan wrote: > > ----- On 11 Oct, 2015, at 4:17 PM, wraeth wra...@wraeth.id.au wrote: > > > >> On 11/10/15 18:52, Ian Delaney wrote: > >>> On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier > >>> <aball...@gentoo.org> wrote: > >>> > >>>> On Sat, 10 Oct 2015 10:09:11 +0200 Michał Górny > >>>> <mgo...@gentoo.org> wrote: > >>>> > >>>>> Hello, developers. > >>>>> > >>>>> I have the pleasure > >>> > >>> :? > >>> > >>>>> to announce that we have formed a new Reviewers team [1] for > >>>>> Gentoo. The team is going to assemble developers willing to > >>>>> perform ebuild reviews and help contributors improve their > >>>>> ebuild skills. > >>>>> > >>>>> The main goal of the team is to handle GitHub pull requests. We > >>>>> are going to review incoming PRs, communicate with maintainers > >>>>> and merge them as appropriate. In particular, we're going to > >>>>> help willing contributors get high-quality, PGP-signed commits > >>>>> into Gentoo, therefore helping them prepare to become Gentoo > >>>>> developers. > >>>> > >>>> This is cool > >>>> > >>>>> The side goal is to review current Gentoo commits for major QA > >>>>> violations and other issues, aiming at improving the quality > >>>>> of ebuilds in Gentoo and helping other developers using bash, > >>>>> ebuilds and git effectively. > >>>> > >>>> This is completely unrelated: since we've had gentoo-commits ml, > >>> > >>> which was promptly utlised > >>> > >>>> every one has been able to do commit reviews easily, and most > >>>> devs have done so. Self-proclamed reviewers project certainly > >>>> does not have the monopoly of best practices nor perfect > >>>> knowledge. I hope they do keep the monopoly of being harassing > >>>> though :) > >>>> > >>>> Also, you should probably focus on what's really important: > >>>> reviews like "this is weird, care to explain?" or stylistic > >>>> nitpicks are just a waste of every one time, meaning more > >>>> important stuff does not get done. > >>>> > >>> > >>> To my observation the reaction to this has been between displeasure > >>> and dismay. Yesterday the dev-ML was flooded with the first day's > >>> publication of the members' reviews. Firstly the gentoo-commits ML > >>> to my understanding is intended to be used for and by qa members. > >>> This project has one whom we presume has the discretion to declare > >>> the use of the qa hat at whim. > >>> > >>> As someone once put it, it's not the product or message it's the > >>> delivery of the package. This project in its creation is made of > >>> self appointed members who assume the status and qualification to > >>> suddenly launch their evaluations upon unsuspecting folk the > >>> community wide with neither warning nor their prior knowledge nor > >>> consent. The editing to the page illustrates already significant > >>> back pedalling from feedback already challenging its selected mode > >>> of delivery. > >>> > >>> The project goals and 'would be' mission statement are in fact > >>> legitimate and have the backing of Council members. The execution > >>> has been done independently, unilaterally and with no input or > >>> collaboration with Council to my knowledge. The actions of this > >>> project potentially impact on every developer / user of the gentoo > >>> project, addressing the core skills of both. Yet it has been made, > >>> announced and executed in this style. > >>> > >>> I invested study time in several units in teaching and lecturing in > >>> my university education under the education department. Sorry but > >>> the modi operandi by these self proclaimed teachers and educators > >>> thus far violate almost every fundamental principle in the art of > >>> teaching that I learned from the course. There have also been users > >>> who have expressed concern to me over this directly, some of which > >>> have indicated they will also email this list to make their views > >>> known. > >> > >> I am one of the users who spoke to idella4 about this, but I wanted to > >> repeat this publicly in order to highlight the point of view of > >> contributing user as opposed to a developer. > >> > >> Firstly I would like to say that I appreciate feedback on my work - it > >> helps me to improve the quality of my work both for Gentoo and personally. > >> > >> I also agree whole-heartedly to the concept of the Reviewers project, in > >> that highlighting common improvements that could be made would benefit > >> both contributors who participate and Gentoo as a whole. > >> > >> Having said that, however, I do not appreciate the method in which these > >> criticisms were delivered, and believe it extends beyond the idea of > >> the Reviewers project. > >> > >> I feel that it is inappropriate for criticisms of contributor's work to > >> be broadcast on a mailing list that is read not only by the developer > >> community, but by users as well, without their consent. This is not a > >> case where I am particularly embarrassed or upset - if others can learn > >> from my mistakes, then they are mistakes I am happy to make (preferably > >> only once). But doing so publicly, with identifying information, is > >> inappropriate. > > > > I will second your thoughts on this. > > As a new proxy-maintainer I expect a lot of feedback, and I welcome > > the idea of the reviewers project to help people like me out. > > > > However this could be a little off putting by just sending out to > > a general mailing list. Maybe there is a better way to give this feedback? > > > > Thanks > > Brendan > > > > It might be also worth to think about limiting the feedback to the > actual patch that is included in a pull request or whatever is used as > transport media. > I have the feeling that some pull requests are accepted, after the > package has been refactored or mistakes or deprecated styles former > maintainers applied have been fixed. I'm not sure if new contributors > like that kind of extra work to get their pull requests accepted or feel > overloaded by the mass of comments some ancient ebuilds may produce. > > A reasonable compromise would be to split review into must-have and > can-have feedback, of which must-have is limited to the issue a pull > request urges to fix. As far as I know, there was only one contributor complaining about the extra review, and it was a particular person that reacted aggressively to any kind of constructive criticism, so I wouldn't consider him relevant. I tend to make it clear which changes are important and which are not. As you can see, there were pull requests accepted without all of the issues being fixed or even with my personal fixes added on top. However, I usually prefer to ask the contributor if he wants to improve the ebuild. If he does, he gets extra kudos and improves his ebuild skills. If he doesn't, he can at least look through the existing issues not to repeat them in his own work. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgpiKOxXMj9SY.pgp
Description: OpenPGP digital signature
