Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Matthias Maier]

Just a comment before this discussion gets entirely side tracked.



On Mon, Oct 12, 2015, at 11:45 CDT, Ian Delaney  wrote:

> [...]

> Users are neither seasoned nor prepared for the type of review put
> upon them by him and mgorny.

My impression is that the reception of the code review on github is
predominantly positive. The point is - we _have_ to do some sort of code
review prior to merging (or stick to the old "let a developer do all the
work" workflow we suffered from all the years).

A very nice example of how this can be facilitated to get a lot of user
contributions is the science overlay - and I think the current review
for gentoo/gentoo is not far away from the approach, word choice, or
debate culture we have there.


> These users still needed support and a voice to help them speak up, and
> they did. Still, these members have fashioned themselves to teach and
> service users, They have alot of adapting to do before users will
> embrace their attempts to educate them.

Seriously? Shall we now all take an online tutorial in order to be
qualified to "help out"? Or shall we just merge every pull-request in
order to not have to interact with users?



There are some observations for Julian and Michał (as the two primary
reviewer on github) that I have, though. I think it might be worthwhile
to think about it and maybe "codify" it in the reviewer best practices
(if not already present):


 - I suggest that only one reviewer administers a given pull-request at
   a time. I have seen two instances where first Julian had roughly 20
   remarks and after those were resolved Michał slabbed another 10 code
   remarks on top of it.

   This seems to be a bit over the top. It feels a bit like vultures
   tearing apart dead prey ;-)

   The bottom line should be that if one Gentoo developer is satisfied
   with the state of a pull-request it should be okay.


 - With respect to the current post- "peer review" of commits: I suggest
   that comments on coding style (if not violating our indent rules) and
   other personal choice is kept at a bare minimum (or avoided
   entirely). While I appreciate comments on factual errors I have
   commited [1], I totally hate discussing something like whether a "\"
   might be omitted in bash or not.


 - Further, "weird" or "unusual" choices of, e.g., how to form up a
   configuration variable might be due to historical (and sometimes
   political reasons). For example, because of a switch of
   maintainership, or due to a developer just "helping out" (and
   obviously avoiding invasive, large changes).

   Thus, comments like "this is hard to read", "why do you do it like
   that" are usually more annoying than helpful [2].


 - And last, keep in mind that discussing the current state of an ebuild
   on a version bump is equivalent to discussing an arbitrary amount of
   commits over the last years (and given the vivid history of some
   ebuilds of code fragments from a lot of people).

   An example here would be the missing "|| die" statements on a sed
   statement that manipulated an entirely gentoo-developer controlled
   configuration file [3]. While it is technically correct that a "die"
   is missing - it doesn't hurt terribly much either (no file involved
   is controlled by upstream and might silently change during a version
   bump).


Best,
Matthias



[1] Julian, thanks again for catching this silly typo in
app-emulation/libvirt :-D

[2] notwithstanding whether the comments are correct/justified on a
purely technical level.

[3] again app-emulation/libvirt

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ciaran McCreesh]

On Mon, 12 Oct 2015 13:13:15 +0800
Ian Delaney wrote:
> The main target learners here are keen users.  You can take told a
> mistake with the background and status of a dev. They don't. They are
> often intimidated and fearful if gentoo devs. We wonder why.

So how about letting them that if they make a mistake, there are now
ways of rectifying that quickly?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ian Delaney]

On Mon, 12 Oct 2015 08:19:34 -0700
Matt Turner  wrote:

> On Mon, Oct 12, 2015 at 7:23 AM, hasufell  wrote:
> >
> > I'm not a native speaker and people have more than once told you
> > that your language is difficult to understand.
> >
> > So, can you elaborate what your sarcastic (that's how I read it)
> > anecdote was meant for then? Preferably off-list, since this doesn't
> > seem to help any of us.
> 
> I am a native speaker and I cannot understand what he's saying, for
> what it's worth.
> 
> I think he's indicating that the "right" in his earlier message was
> indicative of sarcasm, and so then he chides you for responding to his
> sarcastic message without knowing it was sarcasm. 

fwiw how about not sure what you mean by that please re-sate. Better
that than misinterpreting and responding to a totally wrong message.
This was an innocent accident mostly.    is to help all us who
cannot write ebuilds correctly or proficiently?  I generally don't do
sarcasm however with this thread it can be hard to avoid. right is
ambiguous here. He read it as:

all us who cannot write ebuilds, right?
or
all us who cannot write ebuilds? Right?

completely changing the meaning to

all us who cannot write ebuilds at all?
The sentence started out as a question so finishing with

ebuilds right?  unfortunately mislead him. Never intended. The sentence
was too long. I should have simply stopped it with 

How exactly may I ask does anyone actually offer help to the Reviewers
Project?
Confusing or misleading him was never my intent or goal. He has enough
of that already.

The absurd thing is
> that he then says "Please stop taking words out of my mouth and
> distorting my message" (which of course you weren't doing), which was
> *precisely* what he was doing.
> 

I was doing no such thing and I resent this accusation in the strongest
terms.  My meaning here was that he took the 'right' out or the
sentence, or question, equating to taking out.  Any distortion here was
accidental and unfortunate and you need not add to the tension by
accusing me of distortion.


The user here is indeed the exception to the rule, or the norm. And as
rich0 said, the 80% 20% rule may apply. The fact is however that the
20% were grossly unimpressed.  Users are neither seasoned nor prepared
for the type of review put upon them by him and mgorny. Even Amynka
struggled with it. Read the rest of the emails dev to dev and it's a
walk in the park. It all works.  His efforts aimed at devs developing
ebuilds are fine and happy with them.  

These users still needed support and a voice to help them speak up, and
they did. Still, these members have fashioned themselves to teach and
service users, They have alot of adapting to do before users will
embrace their attempts to educate them.

> In another subthread I really got the sense that he's simply
> attempting to provoke a response. I suggest not giving him that.
> 

I won't be giving any more to him I suspect.

enough it's late

-- 
kind regards

Ian Delaney

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Matt Turner]

On Mon, Oct 12, 2015 at 7:23 AM, hasufell  wrote:
> On 10/12/2015 04:12 PM, Ian Delaney wrote:
>> On Mon, 12 Oct 2015 15:47:19 +0200
>> hasufell  wrote:
>>
>>> On 10/12/2015 03:29 PM, Ian Delaney wrote:

 Not sure how to read this. The whole idea is for provider / client
 to communicate and negotiate a workable solution. At a glance this
 reads as the user needs to adapt to the service that the client is
 offering and appease the provider. What's wrong with this picture?

 How exactly may I ask does anyone actually offer help to the
 Reviewers project whose whole aim it seems is to help all us who
 cannot write ebuilds right?

>>>
>>> Nowhere did way say that people cannot write ebuilds, nor did we
>>> impose that picture. That all happened in your own mind.
>>>
>>
>> Yes Julian. Neither did I Julian. I said 'who cannot write ebuilds
>> RIGHT'. Please stop taking words out of my mouth and distorting my
>> message.
>>
>
> I'm not a native speaker and people have more than once told you that
> your language is difficult to understand.
>
> So, can you elaborate what your sarcastic (that's how I read it)
> anecdote was meant for then? Preferably off-list, since this doesn't
> seem to help any of us.

I am a native speaker and I cannot understand what he's saying, for
what it's worth.

I think he's indicating that the "right" in his earlier message was
indicative of sarcasm, and so then he chides you for responding to his
sarcastic message without knowing it was sarcasm. The absurd thing is
that he then says "Please stop taking words out of my mouth and
distorting my message" (which of course you weren't doing), which was
*precisely* what he was doing.

In another subthread I really got the sense that he's simply
attempting to provoke a response. I suggest not giving him that.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Alexis Ballier]

On Mon, 12 Oct 2015 15:53:42 +0200
hasufell  wrote:

> On 10/12/2015 03:41 PM, Alexis Ballier wrote:
> > 
> > They might have failed to notify it,  
> 
> I did that 2 hours ago already on this thread. What does that tell
> us ;)


yes, I noticed from there :p

what I meant was rather that it hadn't been advertised enough yet :)

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 04:12 PM, Ian Delaney wrote:
> On Mon, 12 Oct 2015 15:47:19 +0200
> hasufell  wrote:
> 
>> On 10/12/2015 03:29 PM, Ian Delaney wrote:
>>>
>>> Not sure how to read this. The whole idea is for provider / client
>>> to communicate and negotiate a workable solution. At a glance this
>>> reads as the user needs to adapt to the service that the client is
>>> offering and appease the provider. What's wrong with this picture?
>>>
>>> How exactly may I ask does anyone actually offer help to the
>>> Reviewers project whose whole aim it seems is to help all us who
>>> cannot write ebuilds right?
>>>
>>
>> Nowhere did way say that people cannot write ebuilds, nor did we
>> impose that picture. That all happened in your own mind.
>>
> 
> Yes Julian. Neither did I Julian. I said 'who cannot write ebuilds
> RIGHT'. Please stop taking words out of my mouth and distorting my
> message.
> 

I'm not a native speaker and people have more than once told you that
your language is difficult to understand.

So, can you elaborate what your sarcastic (that's how I read it)
anecdote was meant for then? Preferably off-list, since this doesn't
seem to help any of us.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ian Delaney]

On Mon, 12 Oct 2015 15:47:19 +0200
hasufell  wrote:

> On 10/12/2015 03:29 PM, Ian Delaney wrote:
> > 
> > Not sure how to read this. The whole idea is for provider / client
> > to communicate and negotiate a workable solution. At a glance this
> > reads as the user needs to adapt to the service that the client is
> > offering and appease the provider. What's wrong with this picture?
> > 
> > How exactly may I ask does anyone actually offer help to the
> > Reviewers project whose whole aim it seems is to help all us who
> > cannot write ebuilds right?
> > 
> 
> Nowhere did way say that people cannot write ebuilds, nor did we
> impose that picture. That all happened in your own mind.
> 

Yes Julian. Neither did I Julian. I said 'who cannot write ebuilds
RIGHT'. Please stop taking words out of my mouth and distorting my
message.

> Your picture about our goals is completely incorrect and you seem to
> respond to something that's not really our project. So I'd like to ask
> you to take a few moments and actually read our replies and the
> project page, before we derail even further here.
> 

Yes Julian. You have it right and I have it wrong. I feel relieved now

-- 
kind regards

Ian Delaney

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 03:51 PM, Rich Freeman wrote:

> That's why I
> suggested a top-5 list or something like that, which would have weeded
> out false positives and focus more on resolutions and trends than
> individual incidents.
> 

https://wiki.gentoo.org/wiki/Project:Reviewers/Common_issues

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 03:58 PM, wraeth wrote:
> I don't expect everything to have been within the N^th degree of
> perfection from day one; and I honestly hope the Reviewers project
> finds its feet and benefits the community; I just believe that it's
> first day could have been handled better.
> 

We've had that discussed a hundred times now, can we move on? Because
honestly, I don't see how this gets us any further.

If you want to help, do reviews, suggest project page changes, propagate
the project.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[wraeth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/10/15 22:15, hasufell wrote:
> On 10/12/2015 06:44 AM, wraeth wrote:
>> 
>> I am aware of this and that it has been the way for quite some
>> time. However, while it may be the norm in the wider FOSS 
>> community, it has not been the norm on the gentoo-dev list -
>> certainly people will post things specifically for review, or may
>> highlight critical issues; but it has not until recently been a
>> channel for review of any and all commits that the Reviewers
>> inspect.
>> 
>> It is not the fact that there is a review or education process,
>> but that this process was executed with the level of tact and
>> grace becoming of a flock of ducks flying into the side of a
>> building.
>> 
>> This education process was implemented in a way that
>> indiscriminately pointed the finger at contributors, developer
>> and user alike, sometimes for things that mattered, and other
>> times for things that simply didn't. What's more, it was
>> implemented without warning and included publishing who the
>> author of those mistakes was without the contributor knowing that
>> it would be used so (you know, since the whole commit header was
>> in this educational message, too).
>> 
> 
> We already have been working on making an internal policy about
> _how_ and _where_ to review.
> 
> https://wiki.gentoo.org/wiki/Project:Reviewers/Internal_policy

I have noticed this and have been watching it evolve over the last day
or so.

>> What I am saying is that until now contributors to Gentoo have
>> received feedback on their work in channels that they elected,
>> whether it was IRC, Bugzilla, Pull Requests or E-Mail; until
>> suddenly their work (or more accurately, the Reviewers teams
>> issues with their work) were getting broadcast to anyone who is
>> subscribed to this list, regardless of if that contributor wanted
>> that kind of public critiquing.
> 
> And another point that I have to make very clear... while we are 
> certainly trying to find the best suited channel for reviews, the 
> selection of which one is the best is definitely _not_ about "how
> do I minimize public exposure?", but "where is this review
> relevant?" and "where does the author of the patch respond to most
> quickly?".

I can appreciate that it is difficult to find the right channel for
these sort of reviews - it's something that could be useful to a lot
of people. As I've mentioned, I support the idea of the Reviewers
project and welcome feedback to my own work.

> And frankly, if "public exposure" is a problem for you, then
> that's something you have to work on if you like to contribute to
> FOSS. It's not personal, it's technical. We will definitely not
> keep a list of people who are afraid that a review of their code is
> posted somewhere more public (assuming that the ebuild is already
> GPL-2 or similar and public). But we'll try to post it where it is
> relevant and where the author will respond... if that place is
> private mail, then so be it, but again... we'll not keep a list for
> that around. And it will be a learning experience for us too to
> figure out how to approach this best, including the correct place,
> the amount of nitpicking and so on. You cannot expect that
> everything happens at day 1.

A relevant counterpoint to this is:
>> 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).

I expanded upon this in a different reply to earlier message.

It's not the fact that the reviews were posted publicly, it's the fact
that it was done so without warning. And further, while I'm somewhat
taken aback by it myself, it's more the fact that this type sudden
change to how feedback is given affects more than just seasoned
developers, it also affects existing and potential contributors, both
those who are used to the FOSS 'norm' and those who are offering their
first contributions to their favourite project. As I explained in my
other reply, typically when you begin contributing to a FOSS
community, you do so knowing what mechanisms are used for review and
where critiques of your work may end up.

I don't expect everything to have been within the N^th degree of
perfection from day one; and I honestly hope the Reviewers project
finds its feet and benefits the community; I just believe that it's
first day could have been handled better.

Kind Regards;
- -- 
Sam Jorna (wraeth) 
GnuPG Key: B2D9F759
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYbvGwACgkQXcRKerLZ91k1/gD/e3Tbigd1BeEtb6ghOAFZv0Jq
9PmPPbSDrq6v8NfKd5kA/1CQoJnrHzFB38BrHvZHQmvuuQtKG+9kmHQ10WJ5kJD2
=9UP+
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 03:41 PM, Alexis Ballier wrote:
> 
> They might have failed to notify it,

I did that 2 hours ago already on this thread. What does that tell us ;)

 but I think they've taken into
> account most, if not all, of the problems that had been pointed out:
> https://wiki.gentoo.org/wiki/Project:Reviewers/Internal_policy
> 
> 

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Rich Freeman]

On Mon, Oct 12, 2015 at 9:29 AM, Ian Delaney  wrote:
>
> Not sure how to read this. The whole idea is for provider / client to
> communicate and negotiate a workable solution. At a glance this reads
> as the user needs to adapt to the service that the client is offering
> and appease the provider. What's wrong with this picture?

While I agree that this had a bit of a rough start, I don't think it
is realistic for any Gentoo project to tailor how it communicates to
each individual.  By all means find the 80% solution that works for
most, but if having bugs being opened seems to be the best solution,
we can't really have individual developers saying "don't open bugs for
me - just ping me on IRC/email/phone/the-bar-at-the-next-FOSDEM/etc."

I suggest we focus more on finding that common solution.

FWIW I don't see any issue with this stuff being public.  It shouldn't
be personal, and we should be making feedback as helpful as reasonably
possible.  That could be as simple as an email signature that says
"the above feedback is intended to be concise and is targeted at an
experienced Gentoo developer, if you have any questions about how to
handle it please do ABC to get help."  Just having an invitation for
support would probably go a long way, and we could have a separate set
of volunteers (perhaps overlapping) who volunteer to provide this
help.

To the extent that anything is said which shouldn't be said in public,
we probably shouldn't be saying it in private either, at least not in
the context of this project.

My concern with the -dev list was more that it ends up being a lot of
noise for most on the list, not that it is public.  That's why I
suggested a top-5 list or something like that, which would have weeded
out false positives and focus more on resolutions and trends than
individual incidents.

-- 
Rich

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 03:29 PM, Ian Delaney wrote:
> 
> Not sure how to read this. The whole idea is for provider / client to
> communicate and negotiate a workable solution. At a glance this reads
> as the user needs to adapt to the service that the client is offering
> and appease the provider. What's wrong with this picture?
> 
> How exactly may I ask does anyone actually offer help to the Reviewers
> project whose whole aim it seems is to help all us who cannot write
> ebuilds right?
> 

Nowhere did way say that people cannot write ebuilds, nor did we impose
that picture. That all happened in your own mind.

Your picture about our goals is completely incorrect and you seem to
respond to something that's not really our project. So I'd like to ask
you to take a few moments and actually read our replies and the project
page, before we derail even further here.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Alexis Ballier]

On Mon, 12 Oct 2015 21:29:26 +0800
Ian Delaney wrote:

> On Mon, 12 Oct 2015 13:16:01 +0200
> hasufell  wrote:
> 
> > On 10/12/2015 06:56 AM, Matt Turner wrote:  
> > > 
> > > So work with the reviewers to ensure the communication is tactful
> > > and graceful.
> > >   
> > 
> > That would be appreciated. So far, we mostly got people complaining
> > (and some setting up sieve filters to throw all our mails to
> > trash),  
> 
> what does this tell you?
> > but not people offering help. The latter has a bigger chance of
> > actually having an impact.
> > 
> >   
> 
> Not sure how to read this. The whole idea is for provider / client to
> communicate and negotiate a workable solution. At a glance this reads
> as the user needs to adapt to the service that the client is offering
> and appease the provider. What's wrong with this picture?
> 
> How exactly may I ask does anyone actually offer help to the Reviewers
> project whose whole aim it seems is to help all us who cannot write
> ebuilds right? By going along with your flow, with neither question
> nor comment?  Where is the part about the educators leading the way
> with tact and grace? Who is the leader here?
> 

They might have failed to notify it, but I think they've taken into
account most, if not all, of the problems that had been pointed out:
https://wiki.gentoo.org/wiki/Project:Reviewers/Internal_policy

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ian Delaney]

On Mon, 12 Oct 2015 13:16:01 +0200
hasufell  wrote:

> On 10/12/2015 06:56 AM, Matt Turner wrote:
> > 
> > So work with the reviewers to ensure the communication is tactful
> > and graceful.
> > 
> 
> That would be appreciated. So far, we mostly got people complaining
> (and some setting up sieve filters to throw all our mails to trash),

what does this tell you?
> but not people offering help. The latter has a bigger chance of
> actually having an impact.
> 
> 

Not sure how to read this. The whole idea is for provider / client to
communicate and negotiate a workable solution. At a glance this reads
as the user needs to adapt to the service that the client is offering
and appease the provider. What's wrong with this picture?

How exactly may I ask does anyone actually offer help to the Reviewers
project whose whole aim it seems is to help all us who cannot write
ebuilds right? By going along with your flow, with neither question nor
comment?  Where is the part about the educators leading the way with
tact and grace? Who is the leader here?

-- 
kind regards

Ian Delaney

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 06:56 AM, Matt Turner wrote:
> 
> So work with the reviewers to ensure the communication is tactful and 
> graceful.
> 

That would be appreciated. So far, we mostly got people complaining (and
some setting up sieve filters to throw all our mails to trash), but not
people offering help. The latter has a bigger chance of actually having
an impact.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/12/2015 06:44 AM, wraeth wrote:
> 
> I am aware of this and that it has been the way for quite
> some time. However, while it may be the norm in the wider FOSS
> community, it has not been the norm on the gentoo-dev list - certainly
> people will post things specifically for review, or may highlight
> critical issues; but it has not until recently been a channel for review
> of any and all commits that the Reviewers inspect.
> 
> It is not the fact that there is a review or education process, but that
> this process was executed with the level of tact and grace becoming of a
> flock of ducks flying into the side of a building.
> 
> This education process was implemented in a way that indiscriminately
> pointed the finger at contributors, developer and user alike, sometimes
> for things that mattered, and other times for things that simply didn't.
> What's more, it was implemented without warning and included publishing
> who the author of those mistakes was without the contributor knowing
> that it would be used so (you know, since the whole commit header was in
> this educational message, too).
> 

We already have been working on making an internal policy about _how_
and _where_ to review.

https://wiki.gentoo.org/wiki/Project:Reviewers/Internal_policy

> 
> What I am saying is that until now contributors to Gentoo have received
> feedback on their work in channels that they elected, whether it was
> IRC, Bugzilla, Pull Requests or E-Mail; until suddenly their work (or
> more accurately, the Reviewers teams issues with their work) were
> getting broadcast to anyone who is subscribed to this list, regardless
> of if that contributor wanted that kind of public critiquing.
> 

And another point that I have to make very clear... while we are
certainly trying to find the best suited channel for reviews, the
selection of which one is the best is definitely _not_ about "how do I
minimize public exposure?", but "where is this review relevant?" and
"where does the author of the patch respond to most quickly?".

And frankly, if "public exposure" is a problem for you, then that's
something you have to work on if you like to contribute to FOSS. It's
not personal, it's technical. We will definitely not keep a list of
people who are afraid that a review of their code is posted somewhere
more public (assuming that the ebuild is already GPL-2 or similar and
public). But we'll try to post it where it is relevant and where the
author will respond... if that place is private mail, then so be it, but
again... we'll not keep a list for that around. And it will be a
learning experience for us too to figure out how to approach this best,
including the correct place, the amount of nitpicking and so on. You
cannot expect that everything happens at day 1.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[wraeth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/10/15 15:56, Matt Turner wrote:
> On Sun, Oct 11, 2015 at 9:44 PM, wraeth 
> wrote:
>> This education process was implemented in a way that
>> indiscriminately pointed the finger at contributors, developer
>> and user alike, sometimes
> 
> I think this confirms my belief -- that people are misinterpreting
> a mistake as a personal failing and are upset by it being addressed
> in (a new) public forum.

Yes and no. It is part of it (see below) but not the only part.

>> I am not saying feedback is bad. I am not saying that learning to
>> do better is bad.
> 
> Okay, so it's not about embarrassment or having one's work
> scrutinized.

For me personally, no, but see below.

>> What I am saying is that until now contributors to Gentoo have
>> received feedback on their work in channels that they elected,
>> whether it was IRC, Bugzilla, Pull Requests or E-Mail; until
>> suddenly their work (or more accurately, the Reviewers teams
>> issues with their work) were getting broadcast to anyone who is
>> subscribed to this list, regardless of if that contributor wanted
>> that kind of public critiquing.
>> 
>> I hope this clears up this apparent misunderstanding.
> 
> The problem is that the review is being done in... a different
> forum that you expect? Or that it's a forum that more people are
> reading?

That is also part of it - I submit something and expect perhaps a bug
or a ping on IRC; instead I get my submission sent to a public list
with someone telling me what I did wrong.

Now put that in the perspective of someone for whom it's their first
contribution to a major project. What are the chances they'll
contribute a second time? If they new beforehand that it was going to
a public list, then it changes - knowing this, they implicitly (or
explicitly) acknowledge that they're going to publicly critiqued; but
this was a sudden change with arguable comments within these reviews.

Ever had your teacher stand you in front of the class, hold up your
workbook and say "this is wrong"?

> I don't know -- a lot of the value is precisely that -- because
> it's in on gentoo-dev@, everyone reading can learning from others' 
> experiences, whereas if the reviews were in private emails or even 
> public bugzilla most people likely wouldn't see them.

I can understand this sentiment - for a community education project,
having it's input tucked away in some dark corner doesn't benefit
anyone. But having one's contribution unexpectedly published as an
example, good or bad, can be very discouraging; particularly if some
of the comments are preferential or simply wrong (which newer
contributors may not recognise).

Peer review is also a good thing, but again it's something that is
typically entered into with the knowledge that it will be such. If you
asked someone privately for their opinion on something you created and
they proceeded to share it around and get input from everyone else, it
would discourage you from asking that friend again, wouldn't it?

As I've mentioned, I welcome feedback for the improvement it brings
both Gentoo and my own work and I think the concept of the Reviewers
project is a great one; but there is a difference between education
and auditing; and suddenly posting everyone's mistakes, however well
intentioned you are, is certainly more vinegar than honey.

Personally, I like the idea of the "top improvements of the week" as
an aggregate of common possible improvements, or even perhaps an
opt-in participation to have one's code reviewed and published could
work, too - there are a number of ways (and not mutually exclusive
ones) that this could be done, and I look forward to improving my
coding as a result of the project in the future.

Kind Regards;
- -- 
Sam Jorna (wraeth) 
GnuPG Key: B2D9F759
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYbeScACgkQXcRKerLZ91k+5gD+KD468i93dwE7eatHqk2nPbjk
wAFjhuKY2KAnNMh3NvIA+wbeoYAiAHjUot4j9X1mg9mHMEAOGe7qexdwXUvEvR91
=wU4M
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Alexis Ballier]

On Sun, 11 Oct 2015 09:56:28 -0700
Matt Turner  wrote:

> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:
> > 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.
> 
> Good grief. Seriously?
> 
> Mailing list review is the *norm* in the free software world.
> 
> I haven't seen anything noted that should have caused embarrassment.
> 
> This whole thing, as far as I can see, is about improving the quality
> of Gentoo. I have learned from the reviewers reviewing my commits and
> the commits of others. It's extremely valuable to do this in public
> and the idea that noting an error on a public mailing list is somehow
> bad is simply misguided.
> 

I don't think that is the issue. Contributing to a public repo
(gentoo-x86) makes your commits public, so everyone can look at them
and comment.
Reviews started all of the sudden with stylistic nitpicks (sometimes
even wrong), asking people to justify themselves, or even focusing on
irrelevant things, all of which sent to -dev ml making it the majority
of its traffic. This caused bad perception and bad reactions against
reviews, myself first, even if some were actually useful and
interesting.
However, the reviewer project seems to have reacted well to these
critics and has adapted, so I think it'll end up bringing real
improvements indeed.



As for your statement that mailing list review is the norm, well, not
quite here: Some projects require pre-commit reviews by mailing lists,
we don't. When a user wants to submit a patch, he is directed to
bugzilla (or github), not to git send-mail to gentoo-dev ml. Some
projects do post-commit reviews on their -dev ml, but usually the scale
is much smaller, others reply directly to the -commits ml. We use
bugzilla a lot because things are better tracked there: If the review
uncovers real bugs, better use bugzilla. We use -dev ml for discussing
matters of general interest to the community; for discussing every
single coma of a specific ebuild, better do it privately or in a
dedicated ml if several people are interested in it.


Alexis.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ian Delaney]

On Sun, 11 Oct 2015 19:37:23 -0700
Matt Turner  wrote:

> >>
> >> Mailing list review is the *norm* in the free software world.
> >>
> >
> > Oh, the norm
> 
> You're being quite rude with attempted mockery -- actually, the rest
> of your reply is pretty abrupt as well.
> 
> If you want to fight, find someone and some place and  else. Otherwise
> if you're interested in having a reasonable discussion, please read
> on.
> 

Oh so this is a fight? Your words not mine. I thought this was a
discussion. Please stop putting words into my mouth.
> >
> > These educators have already started to learn some lessons of their
> > own. An intrinsic aspect of the flow of teaching / educating is the
> > impact of teacher behaviour upon their learners and a teacher's
> > responsibility as an educator to deal with it productively. What's
> > happening here? Teacher says take it because I gave it to you,now be
> > quiet ?
> 
> No. It's a discussion. Review can be responded to -- reviewers aren't
> intrinsically right.
> 

Oh thanks for reminding me.
> > This is not a captive audience. It's an immediately convenient one.
> > Educators snubbed by their students are not educators. At least not
> > effective ones.  These students are so by nature of their own
> > voluntary participation. They have the option of rejecting these
> > lessons at their whim.
> 
> Patch review is widely accepted as a quality-improving tool. Some have
> had difficulty adjusting to it when coming from, for instance, the
> closed-source world, primarily because they equate making a mistake to
> personal failure (and as such, having it pointed out in public makes
> it worse).
> 
> http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/
> offers a good explanation.
> 
> "The most productive contributors see each mistake they make as a
> growth opportunity, instead of a personal failure."
> 

The main target learners here are keen users.  You can take told a
mistake with the background and status of a dev. They don't. They are
often intimidated and fearful if gentoo devs. We wonder why.

-- 
kind regards

Ian Delaney

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Matt Turner]

On Sun, Oct 11, 2015 at 9:49 PM, NP-Hardass  wrote:
> I'm not sure if this is what Ian is referring to, but between the sheer
> quantity (flooding) and the way I perceived some of the messages to be
> formulated, it all seemed rather abrasive in nature.  Of course this
> was my own viewpoint on how things appeared, and I can't say whether
> that is what Ian or others perceived as well.

gentoo-dev@, the land of super threads. It's because of this mailing
list that I learned that gmail breaks threads at 100 messages.

I certainly haven't had trouble categorizing review threads appropriately.

Can someone point me (privately if you like) to a review they found
abrasive? I think I've read all the review threads, and nothing stood
out to me (but that was before I was specifically looking for such
things).

> Obviously, the goal of the project, which is an admirable one, is to
> provide reviews of commits and improve the quality of submissions both
> current and future.  It's my opinion that the means under which it has
> proceeded thus far undermine the end goal.  I'd love to see commentary
> on commits, but I am not sure that I think that the gentoo-dev list is
> appropriate.  I'd much rather see it happen on the gentoo-commits list.

I find the suggestion to use gentoo-commits@ for review illogical if
the quantity of mail received is a problem. :)

> Additionally, as mentioned by many others in this thread on all sides
> of the issue, the goal is to provide feedback and improve both
> users(whether they be end users or developers) and their submissions.
> I'd just like to state that those providing feedback should be mindful
> that how they provide that feedback is sometimes as important as the
> feedback itself.  I think care should be taken to be as friendly and
> approachable as possible.  Though some might disagree, I agree with the
> saying "you can catch more flies with honey than vinegar."
>
> Just my two cents of course.  Hopefully it'll help guide this new
> project toward a great future.

Totally agree. Thanks for your reply!

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Matt Turner]

On Sun, Oct 11, 2015 at 9:44 PM, wraeth  wrote:
> I'm not trying to escalate the argument but you seem to have
> misinterpreted my initial message.
>
> On 12/10/15 03:56, Matt Turner wrote:
>> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:
>>> 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.
>>
>> Good grief. Seriously?
>
> Yes, I am being serious. Thanks for asking.
>
>> Mailing list review is the *norm* in the free software world.
>
> I am aware of this and that it has been the way for quite
> some time. However, while it may be the norm in the wider FOSS
> community, it has not been the norm on the gentoo-dev list - certainly
> people will post things specifically for review, or may highlight
> critical issues; but it has not until recently been a channel for review
> of any and all commits that the Reviewers inspect.
>
> It is not the fact that there is a review or education process, but that
> this process was executed with the level of tact and grace becoming of a
> flock of ducks flying into the side of a building.

So work with the reviewers to ensure the communication is tactful and graceful.

FWIW, I haven't seen any review comments that were impolite or
uncivil. Feel free to direct me to them... I've been correcting
miscommunications on gentoo-dev this week...

> This education process was implemented in a way that indiscriminately
> pointed the finger at contributors, developer and user alike, sometimes

I think this confirms my belief -- that people are misinterpreting a
mistake as a personal failing and are upset by it being addressed in
(a new) public forum.

> for things that mattered, and other times for things that simply didn't.
> What's more, it was implemented without warning and included publishing
> who the author of those mistakes was without the contributor knowing
> that it would be used so (you know, since the whole commit header was in
> this educational message, too).
>
>> I haven't seen anything noted that should have caused embarrassment.
>
> Perhaps you missed:
>>> 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).
>
>> This whole thing, as far as I can see, is about improving the
>> quality of Gentoo. I have learned from the reviewers reviewing my
>> commits and the commits of others. It's extremely valuable to do this
>> in public and the idea that noting an error on a public mailing list
>> is somehow bad is simply misguided.
>
> Perhaps you also missed:
>>> 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.
>
> I am not saying feedback is bad. I am not saying that learning to do
> better is bad.

Okay, so it's not about embarrassment or having one's work scrutinized.

> What I am saying is that until now contributors to Gentoo have received
> feedback on their work in channels that they elected, whether it was
> IRC, Bugzilla, Pull Requests or E-Mail; until suddenly their work (or
> more accurately, the Reviewers teams issues with their work) were
> getting broadcast to anyone who is subscribed to this list, regardless
> of if that contributor wanted that kind of public critiquing.
>
> I hope this clears up this apparent misunderstanding.

The problem is that the review is being done in... a different forum
that you expect? Or that it's a forum that more people are reading?

I don't know -- a lot of the value is precisely that -- because it's
in on gentoo-dev@, everyone reading 

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[NP-Hardass]

On Sun, 11 Oct 2015 19:37:23 -0700
Matt Turner  wrote:

> On Sun, Oct 11, 2015 at 5:03 PM, Ian Delaney  
> wrote:
>> On Sun, 11 Oct 2015 09:56:28 -0700 Matt Turner 
>>  wrote:
>> 
>>> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  
>>> wrote:
>> 
 
 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.
>>> 
>>> Good grief. Seriously?
>>> 
>>> Mailing list review is the *norm* in the free software world.
>>> 
>> 
>> Oh, the norm
> 
> You're being quite rude with attempted mockery -- actually, the 
> rest of your reply is pretty abrupt as well.
> 
> If you want to fight, find someone and some place and  else. 
> Otherwise if you're interested in having a reasonable discussion, 
> please read on.
> 
>>> I haven't seen anything noted that should have caused 
>>> embarrassment.
>>> 
>> 
>> Nor I.
>>> This whole thing, as far as I can see, is about improving the 
>>> quality of Gentoo. I have learned from the reviewers reviewing
>>>  my commits and the commits of others.
>> 
>> The you haven't been embarrassed or demeaned or nitpicked. So 
>> far. Good.
>>> It's extremely valuable to do this in public and the idea that
>>>  noting an error on a public mailing list is somehow bad is 
>>> simply misguided.
>>> 
>> 
>> You throw your opinion on that of a user offering his personal 
>> reaction. What do you want here? Users to comply to your 
>> perspective and fit in? Users to tough out the exposure to full 
>> public view even if they don't like it?
> 
> I want to set expectations and explain that noting a mistake is
> not anything to be self-conscious or embarrassed about.
> 
>> Once and for all this is a review put onto recipients whether 
>> they wanted it or not without their request or consent. A key 
>> aspect of learning is that the informative experience be made a 
>> positive one. This user is not alone. These self appointed 
>> educators have background in technical prowess and that's all. 
>> Quite simply, dishing out lessons that make users cringe and 
>> recoil is counter productive. This exercise
> 
> Why and where was a review "dished out" that made someone cringe
> or recoil? I suspect this is just a strawman.
> 
>> is about educating, so these educators had better get their
>> heads around some the fundamental requirement to command respect
>> from their target audience. To date they have managed to deliver
>> their product as they see fit. Now they get the feedback that
>> follows from delivering their lessons.
>> 
>> These educators have already started to learn some lessons of 
>> their own. An intrinsic aspect of the flow of teaching / 
>> educating is the impact of teacher behaviour upon their learners
>>  and a teacher's responsibility as an educator to deal with it 
>> productively. What's happening here? Teacher says take it because
>> I gave it to you,now be quiet ?
> 
> No. It's a discussion. Review can be responded to -- reviewers 
> aren't intrinsically right.
> 
>> This is not a captive audience. It's an immediately convenient 
>> one. Educators snubbed by their students are not educators. At 
>> least not effective ones.  These students are so by nature of 
>> their own voluntary participation. They have the option of 
>> rejecting these lessons at their whim.
> 
> Patch review is widely accepted as a quality-improving tool. Some 
> have had difficulty adjusting to it when coming from, for instance,
> the closed-source world, primarily because they equate making a
> mistake to personal failure (and as such, having it pointed out in
> public makes it worse).
> 
> http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/
>
>
>
> 
offers a good explanation.
> 
> "The most productive contributors see each mistake they make as a 
> growth opportunity, instead of a personal failure."
> 

I'm not sure if this is what Ian is referring to, but between the sheer
quantity (flooding) and the way I perceived some of the messages to be
formulated, it all seemed rather abrasive in nature.  Of course this
was my own viewpoint on how things appeared, and I can't say whether
that is what Ian or others perceived as well.

Obviously, the goal of the project, which is an admirable one, is to
provide reviews of commits and improve the quality of submissions both
current and future.  It's my opinion that the means under which it has
proceeded thus far undermine the end goal.  I'd love to see commentary
on commits, but I am not sure that I think that the gentoo-dev list is
appropriate.  I'd much rather see it happen on the gentoo-commits list.

Additionally, as mentioned by m

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[wraeth]

I'm not trying to escalate the argument but you seem to have
misinterpreted my initial message.

On 12/10/15 03:56, Matt Turner wrote:
> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:
>> 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.
> 
> Good grief. Seriously?

Yes, I am being serious. Thanks for asking.

> Mailing list review is the *norm* in the free software world.

I am aware of this and that it has been the way for quite
some time. However, while it may be the norm in the wider FOSS
community, it has not been the norm on the gentoo-dev list - certainly
people will post things specifically for review, or may highlight
critical issues; but it has not until recently been a channel for review
of any and all commits that the Reviewers inspect.

It is not the fact that there is a review or education process, but that
this process was executed with the level of tact and grace becoming of a
flock of ducks flying into the side of a building.

This education process was implemented in a way that indiscriminately
pointed the finger at contributors, developer and user alike, sometimes
for things that mattered, and other times for things that simply didn't.
What's more, it was implemented without warning and included publishing
who the author of those mistakes was without the contributor knowing
that it would be used so (you know, since the whole commit header was in
this educational message, too).

> I haven't seen anything noted that should have caused embarrassment.

Perhaps you missed:
>> 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).

> This whole thing, as far as I can see, is about improving the
> quality of Gentoo. I have learned from the reviewers reviewing my
> commits and the commits of others. It's extremely valuable to do this
> in public and the idea that noting an error on a public mailing list
> is somehow bad is simply misguided.

Perhaps you also missed:
>> 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.

I am not saying feedback is bad. I am not saying that learning to do
better is bad.

What I am saying is that until now contributors to Gentoo have received
feedback on their work in channels that they elected, whether it was
IRC, Bugzilla, Pull Requests or E-Mail; until suddenly their work (or
more accurately, the Reviewers teams issues with their work) were
getting broadcast to anyone who is subscribed to this list, regardless
of if that contributor wanted that kind of public critiquing.

I hope this clears up this apparent misunderstanding.

Kind Regards;
-- 
Sam Jorna (wraeth) 
GnuPG Key: B2D9F759



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Matt Turner]

On Sun, Oct 11, 2015 at 5:03 PM, Ian Delaney  wrote:
> On Sun, 11 Oct 2015 09:56:28 -0700
> Matt Turner  wrote:
>
>> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:
>
>> >
>> > 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.
>>
>> Good grief. Seriously?
>>
>> Mailing list review is the *norm* in the free software world.
>>
>
> Oh, the norm

You're being quite rude with attempted mockery -- actually, the rest
of your reply is pretty abrupt as well.

If you want to fight, find someone and some place and  else. Otherwise
if you're interested in having a reasonable discussion, please read
on.

>> I haven't seen anything noted that should have caused embarrassment.
>>
>
> Nor I.
>> This whole thing, as far as I can see, is about improving the quality
>> of Gentoo. I have learned from the reviewers reviewing my commits and
>> the commits of others.
>
> The you haven't been embarrassed or demeaned or nitpicked. So far. Good.
>> It's extremely valuable to do this in public
>> and the idea that noting an error on a public mailing list is somehow
>> bad is simply misguided.
>>
>
> You throw your opinion on that of a user offering his personal
> reaction. What do you want here? Users to comply to your perspective
> and fit in? Users to tough out the exposure to full public view even if
> they don't like it?

I want to set expectations and explain that noting a mistake is not
anything to be self-conscious or embarrassed about.

> Once and for all this is a review put onto recipients whether they
> wanted it or not without their request or consent. A key aspect of
> learning is that the informative experience be made a positive one.
> This user is not alone. These self appointed educators have background
> in technical prowess and that's all. Quite simply, dishing out lessons
> that make users cringe and recoil is counter productive. This exercise

Why and where was a review "dished out" that made someone cringe or
recoil? I suspect this is just a strawman.

> is about educating, so these educators had better get their heads
> around some the fundamental requirement to command respect from their
> target audience. To date they have managed to deliver their product as
> they see fit. Now they get the feedback that follows from delivering
> their lessons.
>
> These educators have already started to learn some lessons of their
> own. An intrinsic aspect of the flow of teaching / educating is the
> impact of teacher behaviour upon their learners and a teacher's
> responsibility as an educator to deal with it productively. What's
> happening here? Teacher says take it because I gave it to you,now be
> quiet ?

No. It's a discussion. Review can be responded to -- reviewers aren't
intrinsically right.

> This is not a captive audience. It's an immediately convenient one.
> Educators snubbed by their students are not educators. At least not
> effective ones.  These students are so by nature of their own
> voluntary participation. They have the option of rejecting these
> lessons at their whim.

Patch review is widely accepted as a quality-improving tool. Some have
had difficulty adjusting to it when coming from, for instance, the
closed-source world, primarily because they equate making a mistake to
personal failure (and as such, having it pointed out in public makes
it worse).

http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/
offers a good explanation.

"The most productive contributors see each mistake they make as a
growth opportunity, instead of a personal failure."

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ian Delaney]

On Sun, 11 Oct 2015 09:56:28 -0700
Matt Turner  wrote:

> On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:

> >
> > 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.
> 
> Good grief. Seriously?
> 
> Mailing list review is the *norm* in the free software world.
> 

Oh, the norm
> I haven't seen anything noted that should have caused embarrassment.
> 

Nor I.
> This whole thing, as far as I can see, is about improving the quality
> of Gentoo. I have learned from the reviewers reviewing my commits and
> the commits of others.

The you haven't been embarrassed or demeaned or nitpicked. So far. Good.
> It's extremely valuable to do this in public
> and the idea that noting an error on a public mailing list is somehow
> bad is simply misguided.
> 

You throw your opinion on that of a user offering his personal
reaction. What do you want here? Users to comply to your perspective
and fit in? Users to tough out the exposure to full public view even if
they don't like it?

Once and for all this is a review put onto recipients whether they
wanted it or not without their request or consent. A key aspect of
learning is that the informative experience be made a positive one.
This user is not alone. These self appointed educators have background
in technical prowess and that's all. Quite simply, dishing out lessons
that make users cringe and recoil is counter productive. This exercise
is about educating, so these educators had better get their heads
around some the fundamental requirement to command respect from their
target audience. To date they have managed to deliver their product as
they see fit. Now they get the feedback that follows from delivering
their lessons.

These educators have already started to learn some lessons of their
own. An intrinsic aspect of the flow of teaching / educating is the
impact of teacher behaviour upon their learners and a teacher's
responsibility as an educator to deal with it productively. What's
happening here? Teacher says take it because I gave it to you,now be
quiet ?
 
This is not a captive audience. It's an immediately convenient one.
Educators snubbed by their students are not educators. At least not
effective ones.  These students are so by nature of their own
voluntary participation. They have the option of rejecting these
lessons at their whim.


-- 
kind regards

Ian Delaney

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Matt Turner]

On Sun, Oct 11, 2015 at 1:17 AM, wraeth  wrote:
> 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.

Good grief. Seriously?

Mailing list review is the *norm* in the free software world.

I haven't seen anything noted that should have caused embarrassment.

This whole thing, as far as I can see, is about improving the quality
of Gentoo. I have learned from the reviewers reviewing my commits and
the commits of others. It's extremely valuable to do this in public
and the idea that noting an error on a public mailing list is somehow
bad is simply misguided.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Michał Górny]

Dnia 2015-10-11, o godz. 13:02:50
Manuel Rüger  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
> >>>  wrote:
> >>>
>  On Sat, 10 Oct 2015 10:09:11 +0200 Michał Górny
>   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 embarras

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Michał Górny]

Dnia 2015-10-11, o godz. 15:52:40
Ian Delaney napisał(a):

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

Per GLEP 39, there is no requirement or even a recommendation for
a project to be approved by Council. The Reviewers project has no
special powers. Anyone can post their opinion which includes reviewing
ebuilds or communicating common problems. Some of us has been doing
this for some time already.

The only change about having this project, really, is that there's
a common contact point for people looking for help with ebuilds. This
also improves the quality of reviews through sharing of ebuild
knowledge between different reviewers.

-- 
Best regards,
Michał Górny



pgpPavXDiY6T0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[James Le Cuirot]

On Sun, 11 Oct 2015 13:02:50 +0200
Manuel Rüger  wrote:

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

Nit-picking over mistakes or old standards that the contributor didn't
even add has proven to be quite frustrating. I feel this largely comes
about from the fact that new ebuild revisions appear in a diff as
entirely new content and there's no quick way, at least on GitHub, to
compare it against the previous revision that still exists. It also
seems a tad wasteful as I don't think git will optimize around the fact
that this new revision may have as little as one changed character.
This is where Subversion has the upper-hand as it explicitly supports
copying as well as moving. I tried to think of some clever way around
this but came up empty. :(

I think we should therefore encourage reviewers to not just look at the
raw diff but also compare against the previous revision to see what has
really changed. While mistakes and old standards should be corrected,
if they have already been present, and possibly even stable, for months
or years then they're probably not doing that much harm. We should
allow improvements to be done iteratively.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpih6fMbyp9B.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Alexis Ballier]

On Sun, 11 Oct 2015 13:04:31 +0200
hasufell  wrote:

> On 10/11/2015 09:52 AM, Ian Delaney wrote:
> > 
> > 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.
> > 
> 
> People have been responding to gentoo-commits ML on dev ML since
> years. But mostly on smaller scale. I have no knowledge that this is
> restricted to QA members.

True

> The reason this dev-ML attempt was chosen is that we got very hostile
> and aggressive opinions about our Github activity, telling us it is
> not only against the social contract, but also not properly "public"
> and everything in gentoo should be public on our own infra channels
> (they said).
> 
> So it seems... however you do it, you do it wrong. Github reviews are
> not on our own infra channels, private mails are not public, don't
> spam bugzilla, don't spam the ML... It's not particularly easy to not
> do it wrong when you have so little options.


Draw some line: Stuff that concerns a single, isolated issue, is sent
privately. Repeated issues go to -dev, to let everyone know, stating
clearly that the commit is random and that the issue has been
repeatedly found in various commits from various people.

Once this line is drawn, you'll probably realize what kind of doc or
guide is missing :)


> I suspect this is not even primarily about the chosen platform, but
> about the fact that review culture can introduce a few negative
> thoughts such as embarrassment. In order to fix that, we are going to
> focus the reviews on Github (for developers who are known to be
> active there), private mails and semi-private mails to aliases. In
> addition, it will also require a shift of thinking. Reviews are not
> about exposing a person, but about improving quality and knowledge.
> For both parties.


For what concerns me, please use emails even if I'm active on github:
I've failed to receive several notifications from github in the past,
and I don't monitor everything that happens here.

[...]

Alexis.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/11/2015 09:19 AM, Sven Vermeulen wrote:
> 
> This is good news. There are quite a few developers that manage a small
> subset of packages while doing tremendous work for Gentoo within that
> community. For instance, they focus on particular deliverables in
> repositories which eventually get packaged, or on integration of certain
> components which have a strong, broader community coverage.
> 
> These developers will certainly welcome any helping hand (even post-commit)
> in keeping packages of high quality.
> 
> I hope you will also focus on the documentation side. Certain processes that
> we follow within Gentoo (for commits, for instance the Git workflow) would
> benefit from a good document *set* (yes, set, as you'll definitely want such
> processes to have both a single-screen version as well as an elaborate
> version).
> 
> I've also found myself often looking for similar ebuilds in which a certain
> problem would already have been implemented. For instance, ebuilds with an
> optional python part using the python-r1 eclass. Do you think it is
> worthwhile to have a number of packages assigned as good examples?
> 

Those are great ideas, unfortunately we currently don't have a wiki guru
in the team ;)

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/11/2015 09:52 AM, Ian Delaney wrote:
> 
> 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.
> 

People have been responding to gentoo-commits ML on dev ML since years.
But mostly on smaller scale. I have no knowledge that this is restricted
to QA members.

The reason this dev-ML attempt was chosen is that we got very hostile
and aggressive opinions about our Github activity, telling us it is not
only against the social contract, but also not properly "public" and
everything in gentoo should be public on our own infra channels (they said).

So it seems... however you do it, you do it wrong. Github reviews are
not on our own infra channels, private mails are not public, don't spam
bugzilla, don't spam the ML... It's not particularly easy to not do it
wrong when you have so little options.

I suspect this is not even primarily about the chosen platform, but
about the fact that review culture can introduce a few negative thoughts
such as embarrassment. In order to fix that, we are going to focus the
reviews on Github (for developers who are known to be active there),
private mails and semi-private mails to aliases. In addition, it will
also require a shift of thinking. Reviews are not about exposing a
person, but about improving quality and knowledge. For both parties.

But I guess I have to make one point very clear again: we are not
affiliated with the QA team and this is an attempt to induct peer
reviews (even when private), since this has never happened on larger
scale in gentoo and people were just reverse-fixing mistakes instead of
communicating them in the first place. Which means a great loss for our
self-education.

So it seems a lot of people have got it wrong what the project is about.
It's specifically and explicitly not what the QA team is about, which we
said from the very start. It's not about a reviewers monopoly. It's
about the opposite.

> As someone once put it, it's not the product or message it's the
> delivery of the package

Yeah, so we can either dwell on that or start looking at the actual
product, which I'd expect from the gentoo community.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Manuel Rüger]

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
>>>  wrote:
>>>
 On Sat, 10 Oct 2015 10:09:11 +0200 Michał Górny
  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-maintain

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Alexis Ballier]

On Sat, 10 Oct 2015 20:37:39 +0200
hasufell  wrote:
[...]
> >> This is just a concept of peer-reviewing, which was very difficult
> >> in CVS times.
> > 
> > I fail to see how post-commit reviews are made easier with git.
> > 
> 
> Quite offtopic, but we could discuss this off-list if you want.


You could just have said why. I don't see a difference between
reviewing gentoo-commits from cvs than reviewing gentoo-commits from
git. Maybe there's something you prefer, that I don't use, and I can't
debate your preferences.


> > [...]
> >>> 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.
> >>>
> >>
> >> 'has_version' (which you are probably referring to) as a
> >> conditional for sedding headers is more than just "weird" and
> >> indicates a serious build system bug that needs to be addressed
> >> properly.
> > 
> > It indicates a conditional fix. Just as the code says.
> 
> It's a hack, not a fix. And as such, it is worth discussing.

"It's a hack", "indicates a serious build system bug that needs to be
addressed", etc. : such comments are critics, a bit aggressive, and call
for more aggressiveness. In order to help, and have it welcomed, you
should probably try a bit more of courtesy :)
Not everyone has an "hasufell-translator" reading "hack" as "build
fix" :)

> > Before throwing
> > an email to -dev ml, I would have expected a reviewer to do his
> > homework and try to understand what the condition is, when it will
> > be satisfied, and why this was conditional. There is absolutely
> > nothing wrong about not knowing the answer, but using -dev ml for
> > it is a bit spammy IMHO.
> > 
> 
> I did have a look. I was checking both packages (dev-libs/libcdio and
> dev-libs/libcdio-paranoia) for the header and made up my own mind
> about this. I was still wondering if the maintainer even knows what
> this is about.

I don't think you can make a proper opinion on this without the history
of the split. The code in question is actually correct, it could just
benefit a bit of cleanup for legacy stuff. But again, nobody expects
you to know that.

Reviewing is about pointing out improvements, so in that case that
would be:
"Hi, the code you're sedding is actually only compiled when USE=cdda is
set, which actually always pulls dev-libs/libcdio-paranoia, so it seems
to me the conditional could be dropped for clarity."

This is what makes the difference between helpful reviews and critics
or even testing "if the maintainer even knows what this is about" :)

[...]

Alexis.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Brendan Horan]

- 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
>>  wrote:
>> 
>>> On Sat, 10 Oct 2015 10:09:11 +0200 Michał Górny
>>>  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 

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ian Delaney]

On Sun, 11 Oct 2015 19:17:58 +1100
wraeth  wrote:

> On 11/10/15 18:52, Ian Delaney wrote:
> > On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier
> >  wrote:
> > 
> 
> 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.
> 
> Like I said, I welcome input that would improve my contributions, but
> I am concerned that the way that the Reviewers project has been
> undertaken so far is leading more into an extended QA with standards
> that go beyond the enforcement of established Gentoo policy.
> 
> Kind Regards;
> 

I support wraeth's views. He is a keen and fine contributor to gentoo

-- 
kind regards

Ian Delaney


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[wraeth]

On 11/10/15 18:52, Ian Delaney wrote:
> On Sat, 10 Oct 2015 16:27:15 +0200 Alexis Ballier
>  wrote:
> 
>> On Sat, 10 Oct 2015 10:09:11 +0200 Michał Górny
>>  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.

Like I said, I welcome input that would improve my contributions, but
I am concerned that the way that the Reviewers project has been
undertaken so far is leading more into an extended QA with standards
that go beyond the enforcement of established Gentoo policy.

Kind Regards;

-- 
Sam Jorna (wraeth) 
GnuPG Key: B2D9F759



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Ian Delaney]

On Sat, 10 Oct 2015 16:27:15 +0200
Alexis Ballier  wrote:

> On Sat, 10 Oct 2015 10:09:11 +0200
> Michał Górny  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.


-- 
kind regards

Ian Delaney

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Sven Vermeulen]

On Sat, Oct 10, 2015 at 10:09:11AM +0200, Michał Górny wrote:
> 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.
> 
> 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.
> 
> [1]:https://wiki.gentoo.org/wiki/Project:Reviewers

This is good news. There are quite a few developers that manage a small
subset of packages while doing tremendous work for Gentoo within that
community. For instance, they focus on particular deliverables in
repositories which eventually get packaged, or on integration of certain
components which have a strong, broader community coverage.

These developers will certainly welcome any helping hand (even post-commit)
in keeping packages of high quality.

I hope you will also focus on the documentation side. Certain processes that
we follow within Gentoo (for commits, for instance the Git workflow) would
benefit from a good document *set* (yes, set, as you'll definitely want such
processes to have both a single-screen version as well as an elaborate
version).

I've also found myself often looking for similar ebuilds in which a certain
problem would already have been implemented. For instance, ebuilds with an
optional python part using the python-r1 eclass. Do you think it is
worthwhile to have a number of packages assigned as good examples?

Wkr,
Sven Vermeulen

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/10/2015 05:34 PM, Alexis Ballier wrote:
> 
> It is no secret that I don't care about "hats" :)
> If someone is right, he's right, a QA hat doesn't make something wrong
> magically right. Also, if you'd ask me, QA should be more about Quality
> Assurance, meaning training people, writing docs, fixing trivial
> stuff, helping devs to improve; which implies reviewer project fits
> perfectly. "you must do this" statements shouldn't even be needed, and
> are completely useless in a volunteer-based project anyway :)
> 

QA has the right to remove commit access, so I'm not sure I agree. But I
certainly don't think this is anything important for the Reviewers
project, since the goal is not to remove peoples commit access, but to
teach each other. So I also don't see why we should be affiliated with
the QA project. Since the only difference would be that said power,
which I am not interested in.

In addition, conflicting projects are explicitly allowed in Gentoo as
per GLEP 39, see https://wiki.gentoo.org/wiki/GLEP:39#Specification

>> This is just a concept of peer-reviewing, which was very difficult in
>> CVS times.
> 
> I fail to see how post-commit reviews are made easier with git.
> 

Quite offtopic, but we could discuss this off-list if you want.

> [...]
>>> 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.
>>>
>>
>> 'has_version' (which you are probably referring to) as a conditional
>> for sedding headers is more than just "weird" and indicates a serious
>> build system bug that needs to be addressed properly.
> 
> It indicates a conditional fix. Just as the code says.

It's a hack, not a fix. And as such, it is worth discussing.

> Before throwing
> an email to -dev ml, I would have expected a reviewer to do his homework
> and try to understand what the condition is, when it will be satisfied,
> and why this was conditional. There is absolutely nothing wrong about
> not knowing the answer, but using -dev ml for it is a bit spammy IMHO.
> 

I did have a look. I was checking both packages (dev-libs/libcdio and
dev-libs/libcdio-paranoia) for the header and made up my own mind about
this. I was still wondering if the maintainer even knows what this is about.

So, maybe you should be more careful with throwing accusations around if
people did their homework or not ;)

And that is certainly something the reviewers will not do. For any given
review, it will be irrelevant who wrote the code.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Alexis Ballier]

On Sat, 10 Oct 2015 16:44:45 +0200
hasufell  wrote:

> On 10/10/2015 04:27 PM, Alexis Ballier wrote:
> >> 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,
> > 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 :)
> > 
> 
> We are not a subproject of the QA team and have no hats to throw
> around. Nothing we say is a "you must do this" statement. Only QA can
> do that.

It is no secret that I don't care about "hats" :)
If someone is right, he's right, a QA hat doesn't make something wrong
magically right. Also, if you'd ask me, QA should be more about Quality
Assurance, meaning training people, writing docs, fixing trivial
stuff, helping devs to improve; which implies reviewer project fits
perfectly. "you must do this" statements shouldn't even be needed, and
are completely useless in a volunteer-based project anyway :)

> This is just a concept of peer-reviewing, which was very difficult in
> CVS times.

I fail to see how post-commit reviews are made easier with git.

[...]
> > 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.
> > 
> 
> 'has_version' (which you are probably referring to) as a conditional
> for sedding headers is more than just "weird" and indicates a serious
> build system bug that needs to be addressed properly.

It indicates a conditional fix. Just as the code says. Before throwing
an email to -dev ml, I would have expected a reviewer to do his homework
and try to understand what the condition is, when it will be satisfied,
and why this was conditional. There is absolutely nothing wrong about
not knowing the answer, but using -dev ml for it is a bit spammy IMHO.

Alexis.

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[hasufell]

On 10/10/2015 04:27 PM, Alexis Ballier wrote:
>> 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,
> 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 :)
> 

We are not a subproject of the QA team and have no hats to throw around.
Nothing we say is a "you must do this" statement. Only QA can do that.

This is just a concept of peer-reviewing, which was very difficult in
CVS times.

The project isn't even strictly requried, but just an attempt to
formalize this and maybe make other people do it too.

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

'has_version' (which you are probably referring to) as a conditional for
sedding headers is more than just "weird" and indicates a serious build
system bug that needs to be addressed properly.
has_version also doesn't always work as someone might think it works.

But I agree. We'll work on project policies in the next few days
probably. But the scope will definitely not just be "build failures".

Re: [gentoo-dev] [RFC/announcement] Reviewers project

[Alexis Ballier]

On Sat, 10 Oct 2015 10:09:11 +0200
Michał Górny  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,
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.