Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Robert Haas
On Tue, Jun 25, 2013 at 2:27 PM, Andrew Dunstan and...@dunslane.net wrote:
 I'd like to see prizes each release for best contribution and best
 reviewer - I've thought for years something like this would be worth
 trying. Committers and core members should not be eligible - this is about
 encouraging new people.

Encouraging new people is good, but recognizing sustained, long-term
contributions is good, too.  I think we should do more of that, too.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Christopher Browne
On Thu, Jun 27, 2013 at 10:37 AM, Robert Haas robertmh...@gmail.com wrote:

 On Tue, Jun 25, 2013 at 2:27 PM, Andrew Dunstan and...@dunslane.net
 wrote:
  I'd like to see prizes each release for best contribution and best
  reviewer - I've thought for years something like this would be worth
  trying. Committers and core members should not be eligible - this is
 about
  encouraging new people.

 Encouraging new people is good, but recognizing sustained, long-term
 contributions is good, too.  I think we should do more of that, too.


Conforming with David Fetter's pointer to the notion that sometimes attempts
to reward can backfire, I'm not sure that it will be super-helpful to
create special
rewards.

On the other hand, to recognize reviewer contributions in places relevant
to where
they take place seems pretty apropos, which could include:

a) Obviously we already capture this in the CommitFest web site (but it's
worth mentioning when trying to do a census)

b) It would be a pretty good thing to mention reviewers within commit notes;
that provides some direct trace-back as to who it was that either validated
that the change was good, or that let a bad one slip through.

c) The release notes indicate authors of changes; to have a list of
reviewers
would be a fine thing.

If it requires inordinate effort to get the reviewers directly attached to
each
and every change, perhaps it isn't worthwhile to go to extreme efforts to
that
end.

It could be pretty satisfactory to have a simple listing, in the release
notes,
of the set of reviewers.  That's a lot less bookkeeping than tracking this
for
each and every change.

The statement of such a list is a public acknowledgement of those that help
assure that the quality of PostgreSQL code remains excellent. (And that may
represent a good way to sell this kudo.)

This allows organizations that are sponsoring PostgreSQL development to
have an extra metric by which *they* can recognize that their staff that
do such work are being recognized as contributors.  It seems to me that
this is way more useful than a free t-shirt or the like.


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Bruce Momjian
On Thu, Jun 27, 2013 at 11:50:07AM -0400, Christopher Browne wrote:
 b) It would be a pretty good thing to mention reviewers within commit notes;
 that provides some direct trace-back as to who it was that either validated
 that the change was good, or that let a bad one slip through.
 
 c) The release notes indicate authors of changes; to have a list of reviewers
 would be a fine thing.
 
 If it requires inordinate effort to get the reviewers directly attached to 
 each
 and every change, perhaps it isn't worthwhile to go to extreme efforts to that
 end.
 
 It could be pretty satisfactory to have a simple listing, in the release 
 notes,
 of the set of reviewers.  That's a lot less bookkeeping than tracking this for
 each and every change.

Adding the names to each release note item is not a problem;  the
problem is the volume of names that overwhelms the release note text.  If
we went that direction, I predict we would just remove _all_ names from
the release notes.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Andrew Dunstan


On 06/27/2013 12:12 PM, Tom Lane wrote:

Bruce Momjian br...@momjian.us writes:

On Thu, Jun 27, 2013 at 11:50:07AM -0400, Christopher Browne wrote:

It could be pretty satisfactory to have a simple listing, in the
release notes, of the set of reviewers.  That's a lot less
bookkeeping than tracking this for each and every change.

Adding the names to each release note item is not a problem;  the
problem is the volume of names that overwhelms the release note text.  If
we went that direction, I predict we would just remove _all_ names from
the release notes.

Yeah.  Keep in mind that the overwhelming majority of the audience for
the release notes doesn't actually give a darn who implemented what.



Maybe we should have a Kudos / Bragging rights wiki page, with a table 
something like this:


   Release
   Feature Name
   Principal Author(s)
   Contributing Author(s)
   Code Reviewer(s)
   Tester(s)


Constructing it going backwards would be an interesting task :-)


cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Tom Lane
Bruce Momjian br...@momjian.us writes:
 On Thu, Jun 27, 2013 at 11:50:07AM -0400, Christopher Browne wrote:
 It could be pretty satisfactory to have a simple listing, in the
 release notes, of the set of reviewers.  That's a lot less
 bookkeeping than tracking this for each and every change.

 Adding the names to each release note item is not a problem;  the
 problem is the volume of names that overwhelms the release note text.  If
 we went that direction, I predict we would just remove _all_ names from
 the release notes.

Yeah.  Keep in mind that the overwhelming majority of the audience for
the release notes doesn't actually give a darn who implemented what.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Greg Smith

On 6/25/13 2:44 PM, Josh Berkus wrote:

On the other hand, I will point out that we currently have a shortage of
reviewers, and we do NOT have a shortage of patch submitters.


That's because reviewing is harder than initial development.  The only 
people who think otherwise are developers who don't do enough review.


--
Greg Smith   2ndQuadrant USg...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Josh Berkus
On 06/27/2013 08:56 AM, Bruce Momjian wrote: Adding the names to each
release note item is not a problem;  the
 problem is the volume of names that overwhelms the release note text.  If
 we went that direction, I predict we would just remove _all_ names from
 the release notes.

That's not a realistic objection.  We'd be talking about one or two more
names per patch, with a handful of exceptions.

If you're going to make an objection, object to the amount of extra work
it would be, which is signigficant with the current state of our
technology.  Realistically, it'll take the help of additional people.

On 06/27/2013 09:19 AM, Tom Lane wrote:
 Yeah.  Keep in mind that the overwhelming majority of the audience for
 the release notes doesn't actually give a darn who implemented what.

There is some argument to be made about moving the whole list of names
to some other resource, like a web page.  In fact, if the mythical land
where we have a new CF application, that other resource could even be
generated by the CF app with some hand-tweaking (this would also require
some tweaks to community profiles etc.).

What I would be opposed to is continuing to list the original authors in
the release notes and putting reviewers, testers, co-authors, etc. on a
separate web page.  If we're gonna move people, let's move *all* of
them.  Also, it needs to be on something more trustworthy than the wiki,
like maybe putting it at postgresql.org/developers/9.3/

On Tue, Jun 25, 2013 at 2:27 PM, Andrew Dunstan and...@dunslane.net
wrote:
 Encouraging new people is good, but recognizing sustained, long-term
 contributions is good, too.  I think we should do more of that, too.

I wasn't thinking about doing it every year -- just for 9.3, in order to
encourage more reviewers, and encourage reviewers to do more reviews.
But that would only work if we're also giving reviewers credit; as
several people have said, they care more about credit than they do about
prizes.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Bruce Momjian
On Thu, Jun 27, 2013 at 10:10:23AM -0700, Josh Berkus wrote:
 On 06/27/2013 08:56 AM, Bruce Momjian wrote: Adding the names to each
 release note item is not a problem;  the
  problem is the volume of names that overwhelms the release note text.  If
  we went that direction, I predict we would just remove _all_ names from
  the release notes.
 
 That's not a realistic objection.  We'd be talking about one or two more
 names per patch, with a handful of exceptions.

It is realistic because I did this for 9.2 beta and people didn't like
it;  how much more realistic do you want?

 If you're going to make an objection, object to the amount of extra work
 it would be, which is significant with the current state of our
 technology.  Realistically, it'll take the help of additional people.

No extra work required, it is all copy/paste for me.

 On 06/27/2013 09:19 AM, Tom Lane wrote:
  Yeah.  Keep in mind that the overwhelming majority of the audience for
  the release notes doesn't actually give a darn who implemented what.
 
 There is some argument to be made about moving the whole list of names
 to some other resource, like a web page.  In fact, if the mythical land
 where we have a new CF application, that other resource could even be
 generated by the CF app with some hand-tweaking (this would also require
 some tweaks to community profiles etc.).

Yes, I am fine with moving all names.  However, I predict you will do
more to demotivate patch submitters than you will to motivate patch
reviewers.  That is fine with me, as motivating developers/reviewers is
not our top priority.

 What I would be opposed to is continuing to list the original authors in
 the release notes and putting reviewers, testers, co-authors, etc. on a
 separate web page.  If we're gonna move people, let's move *all* of
 them.  Also, it needs to be on something more trustworthy than the wiki,
 like maybe putting it at postgresql.org/developers/9.3/

I think you will have trouble keeping those two lists synchronized.  I
think you will need to create a release note document that includes all
names, then copy that to a website and remove the names just before the
release is packaged.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Tom Lane
Bruce Momjian br...@momjian.us writes:
 On Thu, Jun 27, 2013 at 10:10:23AM -0700, Josh Berkus wrote:
 What I would be opposed to is continuing to list the original authors in
 the release notes and putting reviewers, testers, co-authors, etc. on a
 separate web page.  If we're gonna move people, let's move *all* of
 them.  Also, it needs to be on something more trustworthy than the wiki,
 like maybe putting it at postgresql.org/developers/9.3/

 I think you will have trouble keeping those two lists synchronized.  I
 think you will need to create a release note document that includes all
 names, then copy that to a website and remove the names just before the
 release is packaged.

Unless Bruce is doing more work than I think he is, the attribution data
going into the release notes is just coming from whatever the committer
said in the commit log message.  I believe that we've generally been
careful to credit the patch author, but I'm less confident that everyone
who merited a review credit always gets mentioned --- that would
require going through the entire review thread at commit time, and I for
one can't say that I do that.

If we're going to try harder to ensure that reviewers are credited,
it'd probably be better to take both the commit log and the release
notes out of that loop.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Josh Berkus

 If we're going to try harder to ensure that reviewers are credited,
 it'd probably be better to take both the commit log and the release
 notes out of that loop.

I'd pull the reviewers out of the CF app.   Even in its current
implementation, that's the easiest route.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Andrew Dunstan


On 06/27/2013 02:38 PM, Josh Berkus wrote:

If we're going to try harder to ensure that reviewers are credited,
it'd probably be better to take both the commit log and the release
notes out of that loop.

I'd pull the reviewers out of the CF app.   Even in its current
implementation, that's the easiest route.



I have not honestly found these to be terribly accurate.

cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Bruce Momjian
On Thu, Jun 27, 2013 at 02:17:25PM -0400, Tom Lane wrote:
 Bruce Momjian br...@momjian.us writes:
  On Thu, Jun 27, 2013 at 10:10:23AM -0700, Josh Berkus wrote:
  What I would be opposed to is continuing to list the original authors in
  the release notes and putting reviewers, testers, co-authors, etc. on a
  separate web page.  If we're gonna move people, let's move *all* of
  them.  Also, it needs to be on something more trustworthy than the wiki,
  like maybe putting it at postgresql.org/developers/9.3/
 
  I think you will have trouble keeping those two lists synchronized.  I
  think you will need to create a release note document that includes all
  names, then copy that to a website and remove the names just before the
  release is packaged.
 
 Unless Bruce is doing more work than I think he is, the attribution data
 going into the release notes is just coming from whatever the committer
 said in the commit log message.  I believe that we've generally been

Yes, that's all I do.  Bruce is doing more work than I think he is
gave me a chuckle.  ;-)

 careful to credit the patch author, but I'm less confident that everyone
 who merited a review credit always gets mentioned --- that would
 require going through the entire review thread at commit time, and I for
 one can't say that I do that.
 
 If we're going to try harder to ensure that reviewers are credited,
 it'd probably be better to take both the commit log and the release
 notes out of that loop.

I assume you are suggesting we _not_ use the commit log and release
notes for reviewer credit.   Good point;  we might be able to pull that
from the commit-fest app, though you then need to match that with the
release note text.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Alvaro Herrera
Andrew Dunstan escribió:
 
 On 06/27/2013 02:38 PM, Josh Berkus wrote:
 If we're going to try harder to ensure that reviewers are credited,
 it'd probably be better to take both the commit log and the release
 notes out of that loop.
 I'd pull the reviewers out of the CF app.   Even in its current
 implementation, that's the easiest route.
 
 I have not honestly found these to be terribly accurate.

Yeah, they're not.  I do take care to review past threads when crediting
reviewers in commit messages, and I don't even bother to look at the CF
app.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-27 Thread Greg Sabino Mullane

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


Josh Berkus wrote:

 I wasn't thinking about doing it every year -- just for 9.3, in order to
 encourage more reviewers, and encourage reviewers to do more reviews.

- -1. It's not cool to set it up and then stop it the next go round.

You want more reviewers? Start by streamlining the process as much as 
possible. I pretended I was new to the project and tried to figure 
out how to review something. The homepage has no mention of reviewers, 
not even if you drill down on some subpages. A Google search does lead 
one to:

http://wiki.postgresql.org/wiki/Reviewing_a_Patch

It has some good you can do it wordage. However, there is no clear path 
on how to actually start reviewing. There is this paragraph with 
two links in it:

  The current commitfest is here[1] and has plenty of room for 
   you to help. You can sign up to become a Round Robin 
   Reviewer here[2]. Once you have, write a mail to the list 
   introducing yourself.

[1] Leads to the commitfest, with a nice summary, but no way for new people 
to know what to do.

[2] This link is even worse (http://www.postgresql.org/list/pgsql-rrreviewers/)
It's an archive list for pgsql-rrreviewers, with no way to subscribe 
and certainly no indication on it or the previous page that sign up 
means (one might guess) join the mailing list.

Anyway, just food for thought as far as attracting new people. It should 
be much easier and more intuitive. As far as rewarding current reviewers, 
put the names in the release notes, after each item. Full stop.

- -- 
Greg Sabino Mullane g...@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201306271636
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAlHMoqIACgkQvJuQZxSWSsgCPACgovKYtxJV59Xro0MlxPDEHIy6
pmAAoOLOAlpO/dPlJbyHypdcY4ZxLCit
=RwMh
-END PGP SIGNATURE-




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Albe Laurenz
Dean Rasheed wrote:
 How should reviewers get credited in the release notes?

 a) not at all
 b) in a single block titled Reviewers for this version at the bottom.
 c) on the patch they reviewed, for each patch

 
 b) Unless they contribute enough to the patch to be considered a co-author.
 
 
 Should there be a criteria for a creditable review?

 a) no, all reviews are worthwhile
 b) yes, they have to do more than it compiles
 c) yes, only code reviews should count

 
 a) Sometimes even it compiles can be worthwhile, if there is doubt
 over platform compatibility. All contributions should be acknowledged
 and encouraged.
 
 
 Should reviewers for 9.4 get a prize, such as a t-shirt, as a
 promotion to increase the number of non-submitter reviewers?

 a) yes
 b) no
 c) yes, but submitters and committers should get it too

 
 b) Getting your name in the fine manual is reward enough ;-)

+1, except that I like Josh's idea about a free ticket to pgCon.

Yours,
Laurenz Albe

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Atri Sharma
For me, B,B and another B works.

Regards,

Atri


--
Regards,

Atri
l'apprenant


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Bruce Momjian
On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
 On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote:
  How should reviewers get credited in the release notes?
 
  a) not at all
  b) in a single block titled Reviewers for this version at the bottom.
  c) on the patch they reviewed, for each patch
 
 A weak preference for (c), with (b) running a close second.  As others
 have suggested, a review that leads to significant commitable changes
 to the patch should bump the credit to co-authorship.

As a reminder, I tried a variant of C for 9.2 beta release notes, and
got lots of complaints, particularly because the line describing the
feature now had many more names on it.

In my opinion, adding reviewer names to each feature item might result
in the removal of all names from features.

A poll is nice for gauging interest, but many people who vote don't
understand the ramifications of what they are voting on.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Andrew Dunstan


On 06/26/2013 09:14 AM, Bruce Momjian wrote:

On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:

On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote:

How should reviewers get credited in the release notes?

a) not at all
b) in a single block titled Reviewers for this version at the bottom.
c) on the patch they reviewed, for each patch

A weak preference for (c), with (b) running a close second.  As others
have suggested, a review that leads to significant commitable changes
to the patch should bump the credit to co-authorship.

As a reminder, I tried a variant of C for 9.2 beta release notes, and
got lots of complaints, particularly because the line describing the
feature now had many more names on it.

In my opinion, adding reviewer names to each feature item might result
in the removal of all names from features.

A poll is nice for gauging interest, but many people who vote don't
understand the ramifications of what they are voting on.




That's why I voted for b :-)

cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Markus Wanner
On 06/25/2013 08:26 PM, Andres Freund wrote:
 It's not about the reviewers being less. It's a comparison of
 effort. The effort for a casual review simply isn't comparable with the
 effort spent on developing a nontrivial patch.

Remember: Debugging is twice as hard as writing the code in the first
place. ... (Brian Kernighan)

IMO, the kind of reviews we need are of almost debug level difficulty.
(To the point where the reviewer becomes a co-author or even takes over
and submits a completely revamped patch instead.)

I agree that the casual review is several levels below that, so your
point holds. I doubt we need more reviews of that kind, though.

Thus, I'm in the AAB camp. The remaining question being: What's the
criterion for becoming a co-author (and thus getting mentioned in the
release notes)?

If at all, we should honor quality work with a prize. Maybe a price
for the best reviewer per CF? Maybe even based on votes from the general
public on who's been the best, so reviews gain attention that way...
Click here to vote for my review. ... Maybe a crazy idea.

Regards

Markus Wanner


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Dimitri Fontaine
Josh Berkus j...@agliodbs.com writes:
 Well, one of the other prizes which occurred to me today would be a
 pgCon lottery.  That is, each review posted by a non-committer would go
 in a hat, and in February we would draw one who would get a free
 registration and airfare to pgCon.

+1, I like that idea!

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Claudio Freire
On Wed, Jun 26, 2013 at 10:25 AM, Andrew Dunstan and...@dunslane.net wrote:

 On 06/26/2013 09:14 AM, Bruce Momjian wrote:

 On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:

 On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote:

 How should reviewers get credited in the release notes?

 a) not at all
 b) in a single block titled Reviewers for this version at the bottom.
 c) on the patch they reviewed, for each patch

 A weak preference for (c), with (b) running a close second.  As others
 have suggested, a review that leads to significant commitable changes
 to the patch should bump the credit to co-authorship.

 As a reminder, I tried a variant of C for 9.2 beta release notes, and
 got lots of complaints, particularly because the line describing the
 feature now had many more names on it.

 In my opinion, adding reviewer names to each feature item might result
 in the removal of all names from features.

 A poll is nice for gauging interest, but many people who vote don't
 understand the ramifications of what they are voting on.



 That's why I voted for b :-)

Yeah, with that in mind, I'd also switch to b.

I wouldn't complain, but if it's been tried and failed... what can I say?


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Rodrigo Gonzalez
On Wed, 26 Jun 2013 09:14:07 -0400
Bruce Momjian br...@momjian.us wrote:

 On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
  On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote:
   How should reviewers get credited in the release notes?
  
   a) not at all
   b) in a single block titled Reviewers for this version at the
   bottom. c) on the patch they reviewed, for each patch
  
  A weak preference for (c), with (b) running a close second.  As
  others have suggested, a review that leads to significant
  commitable changes to the patch should bump the credit to
  co-authorship.
 
 As a reminder, I tried a variant of C for 9.2 beta release notes, and
 got lots of complaints, particularly because the line describing the
 feature now had many more names on it.

I am just someone that is thinking that maybe can review things...I am
not voting OK but I have a comment about your last email...
If people thinks (and with people I am not talking about myself but
regular committers and reviewers) think that option c is good, I think
that we should change the tool (or the way) that release notes are
doneI mean (and excuse my poor English) if people thing that it is
the way to go, we should make tools good enough for what people want
not change people thoughts cause tools are not good enough


 
 In my opinion, adding reviewer names to each feature item might result
 in the removal of all names from features.

Let's fix the way that release notes are done


 
 A poll is nice for gauging interest, but many people who vote don't
 understand the ramifications of what they are voting on.
 

I agree, but cost-benefit is what we should see here not just cost



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Bruce Momjian
On Wed, Jun 26, 2013 at 03:12:00PM -0300, Rodrigo Gonzalez wrote:
 On Wed, 26 Jun 2013 09:14:07 -0400
 Bruce Momjian br...@momjian.us wrote:
 
  On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
   On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote:
How should reviewers get credited in the release notes?
   
a) not at all
b) in a single block titled Reviewers for this version at the
bottom. c) on the patch they reviewed, for each patch
   
   A weak preference for (c), with (b) running a close second.  As
   others have suggested, a review that leads to significant
   commitable changes to the patch should bump the credit to
   co-authorship.
  
  As a reminder, I tried a variant of C for 9.2 beta release notes, and
  got lots of complaints, particularly because the line describing the
  feature now had many more names on it.
 
 I am just someone that is thinking that maybe can review things...I am
 not voting OK but I have a comment about your last email...
 If people thinks (and with people I am not talking about myself but
 regular committers and reviewers) think that option c is good, I think
 that we should change the tool (or the way) that release notes are
 doneI mean (and excuse my poor English) if people thing that it is
 the way to go, we should make tools good enough for what people want
 not change people thoughts cause tools are not good enough

Production of the release notes was not the problem;  it was the text in
the release notes.  I don't see how we could modify the release note
format.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Rodrigo Gonzalez
On Wed, 26 Jun 2013 14:13:32 -0400
Bruce Momjian br...@momjian.us wrote:

 On Wed, Jun 26, 2013 at 03:12:00PM -0300, Rodrigo Gonzalez wrote:
  On Wed, 26 Jun 2013 09:14:07 -0400
  Bruce Momjian br...@momjian.us wrote:
  
   On Wed, Jun 26, 2013 at 10:40:17AM +1000, Brendan Jurd wrote:
On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote:
 How should reviewers get credited in the release notes?

 a) not at all
 b) in a single block titled Reviewers for this version at
 the bottom. c) on the patch they reviewed, for each patch

A weak preference for (c), with (b) running a close second.  As
others have suggested, a review that leads to significant
commitable changes to the patch should bump the credit to
co-authorship.
   
   As a reminder, I tried a variant of C for 9.2 beta release notes,
   and got lots of complaints, particularly because the line
   describing the feature now had many more names on it.
  
  I am just someone that is thinking that maybe can review things...I
  am not voting OK but I have a comment about your last email...
  If people thinks (and with people I am not talking about myself but
  regular committers and reviewers) think that option c is good, I
  think that we should change the tool (or the way) that release
  notes are doneI mean (and excuse my poor English) if people
  thing that it is the way to go, we should make tools good enough
  for what people want not change people thoughts cause tools are not
  good enough
 
 Production of the release notes was not the problem;  it was the text
 in the release notes.  I don't see how we could modify the release
 note format.
 

Well...

Checking release notes for 9.2.4

you have Fix insecure parsing of server command-line switches
(Mitsumasa Kondo, Kyotaro Horiguchi)

What about (it people think that it is good) a second () with reviewed
by someone


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Bruce Momjian
On Wed, Jun 26, 2013 at 03:22:06PM -0300, Rodrigo Gonzalez wrote:
 On Wed, 26 Jun 2013 14:13:32 -0400
  Production of the release notes was not the problem;  it was the text
  in the release notes.  I don't see how we could modify the release
  note format.
  
 
 Well...
 
 Checking release notes for 9.2.4
 
 you have Fix insecure parsing of server command-line switches
 (Mitsumasa Kondo, Kyotaro Horiguchi)
 
 What about (it people think that it is good) a second () with reviewed
 by someone

That's what we had, and people didn't like it.  If we overload that list
of names, we might find we want to remove all the names.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Alvaro Herrera
Bruce Momjian escribió:
 On Wed, Jun 26, 2013 at 03:22:06PM -0300, Rodrigo Gonzalez wrote:

  Checking release notes for 9.2.4
  
  you have Fix insecure parsing of server command-line switches
  (Mitsumasa Kondo, Kyotaro Horiguchi)
  
  What about (it people think that it is good) a second () with reviewed
  by someone
 
 That's what we had, and people didn't like it.  If we overload that list
 of names, we might find we want to remove all the names.

Yeah, it becomes too long.  (For security patches, in particular, it's
probably not wise to list reviewers; there might well be reviewers whose
input you never see because they happened in the closed security list).


See the entry for foreign key locks:

  Prevent non-key-field row updates from locking foreign key rows (Álvaro
  Herrera, Noah Misch, Andres Freund, Alexander Shulgin, Marti Raudsepp)

I am the author of most of the code, yet I chose to add Noah and Andres
because they contributed a huge amount of time to reviewing the patch,
and Alex and Marti because they submitted some code.  They are all
listed as coauthors, which seems a reasonable compromise to me.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Josh Berkus
On 06/26/2013 12:02 PM, Alvaro Herrera wrote:
 See the entry for foreign key locks:
 
   Prevent non-key-field row updates from locking foreign key rows (Álvaro
   Herrera, Noah Misch, Andres Freund, Alexander Shulgin, Marti Raudsepp)
 
 I am the author of most of the code, yet I chose to add Noah and Andres
 because they contributed a huge amount of time to reviewing the patch,
 and Alex and Marti because they submitted some code.  They are all
 listed as coauthors, which seems a reasonable compromise to me.

What about the idea that reviewers who do code revision work, like in
your FK patch, get listed after the original patch author with the
patch, and reviewers do more lightweight reviews get listed at the
bottom of the release notes?  Seems fair to me.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Selena Deckelmann
On Tue, Jun 25, 2013 at 10:17 AM, Josh Berkus j...@agliodbs.com wrote:

 How should reviewers get credited in the release notes?

Without getting into how we do this, I thought it might be helpful to
share the reasons why I believe recognizing and expressing gratitude
to reviewers is a helpful, useful and gratifying exercise for the
Postgres community.

I support crediting reviewers in a more formal way than we currently
do for a few different reasons.

First, I believe it's worth finding a way to say Hey, you just did
something great for Postgres, publicly, to a bunch of people who
could have spent their valuable time and energy in some other way.

Second, reviewers get better at their work by reviewing multiple times
- so I'd like to encourage people to review more than once.

Third, reviewers don't always need to be expert developers, or experts
at Postgres to get started, but many people who do open source work
have no idea this is true. Public recognition helps make it clear that
we have people who give useful reviews and are relative novices.

We also have several different kinds of reviews:

* does it compile
* style/typo/easily seen bug passes
* in-depth discussion of design choices, use case, interface
* complex testing cases
* performance testing
* pre-commit checks for more subtle bugs or committer preferences.

All of those, except probably the very last, can be done by people who
are familiar with Postgres or its configuration, but aren't
necessarily Postgres or C experts.

Fourth, we have very few accepted ways to recognize contributions to
Postgres. Naming in Release Notes is one way this community has
consistently supported as a *public* way to say hey, you just did
something great for Postgres.  The complete list of ways I'm aware of
are:

1. Recognizing major, minor and emeritus contributors
2. Making someone a committer
3. Being part of the -core group
4. Naming authors by name in commit messages (but without consistent
metadata, making it difficult to count well)
5. Naming authors in release notes

That's pretty much it. That's great for the people who have already
secured positions through seniority, or because they're amazing C
hackers.  I don't know if I need to lay out for everyone the value of
public recognition - if you want me to I can enumerate them. But the
benefits of public recognition are huge -- both in a social and a
financial sense.

Currently, the only way I know of to be recognized for work on
Postgres that is *not* seniority or code-related is #1. If you're a
reviewer, there's almost no chance you'll be recognized in that way
without some additional, very significant contribution to our
community. (Please let me know if I'm mistaken about this -- I only
know what I know!)  Adding names to Release Notes (or some variant of
Release Notes) seems like a minor concession for work done that we as
a community value and want to encourage.

We are so few in terms of patch contributors - somewhere between
300-400 people contribute code to PostgreSQL each year based on the
names I try to pull out of commits. I haven't counted how many
reviewers we have who do not also contribute code.

Giving people appreciation for the review work they're doing for this
community, for free, is a good thing for everyone. Naming more names
helps describe the true scope of our community. Spreading gratitude is
good for those who thank and those who receive thanks (like, proven
scientifically!). And we increase the number of people who benefit
directly from the work that they do here, by giving them something
they can point their boss, their company and their colleagues to.

So, when we're debating *how* recognition might be done, please don't
lose sight of *why* this is important in the first place.

-selena


--
http://chesnok.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Michael Paquier
On Thu, Jun 27, 2013 at 1:15 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
 Josh Berkus j...@agliodbs.com writes:
 Well, one of the other prizes which occurred to me today would be a
 pgCon lottery.  That is, each review posted by a non-committer would go
 in a hat, and in February we would draw one who would get a free
 registration and airfare to pgCon.

 +1, I like that idea!
+1 on that also, looks like an excellent idea.
--
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread Mark Kirkwood

On 27/06/13 07:12, Josh Berkus wrote:

On 06/26/2013 12:02 PM, Alvaro Herrera wrote:

See the entry for foreign key locks:

   Prevent non-key-field row updates from locking foreign key rows (Álvaro
   Herrera, Noah Misch, Andres Freund, Alexander Shulgin, Marti Raudsepp)

I am the author of most of the code, yet I chose to add Noah and Andres
because they contributed a huge amount of time to reviewing the patch,
and Alex and Marti because they submitted some code.  They are all
listed as coauthors, which seems a reasonable compromise to me.

What about the idea that reviewers who do code revision work, like in
your FK patch, get listed after the original patch author with the
patch, and reviewers do more lightweight reviews get listed at the
bottom of the release notes?  Seems fair to me.



I note reviewers are usually (?) mentioned in the commits to the git 
repo - so maybe it is enough to list them at the bottom of the release 
notes only?


Regards

Mark


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-26 Thread gabrielle
On Tue, Jun 25, 2013 at 5:40 PM, Brendan Jurd dire...@gmail.com wrote:

 On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote:
  How should reviewers get credited in the release notes?
 
  a) not at all
  b) in a single block titled Reviewers for this version at the bottom.
  c) on the patch they reviewed, for each patch

 A weak preference for (c), with (b) running a close second.  As others
 have suggested, a review that leads to significant commitable changes
 to the patch should bump the credit to co-authorship.


I like the single block at the bottom myself, with the same provision to
move a reviewer up to co-author.


  Should there be a criteria for a creditable review?
 
  a) no, all reviews are worthwhile
  b) yes, they have to do more than it compiles
  c) yes, only code reviews should count

 (b), the review should at least look at usabililty, doc, and
 regression test criteria even if there is no in-depth code analysis.


+1 to this.


  Should reviewers for 9.4 get a prize, such as a t-shirt, as a
  promotion to increase the number of non-submitter reviewers?
 
  a) yes
  b) no
  c) yes, but submitters and committers should get it too


I was going to go with b until I saw the suggestion for a PgCon ticket.  I
really like that idea.

gabrielle


[HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Josh Berkus
Hackers,

I'd like to take a straw poll here on how we should acknowledge
reviewers.  Please answer the below with your thoughts, either on-list
or via private email.

How should reviewers get credited in the release notes?

a) not at all
b) in a single block titled Reviewers for this version at the bottom.
c) on the patch they reviewed, for each patch

Should there be a criteria for a creditable review?

a) no, all reviews are worthwhile
b) yes, they have to do more than it compiles
c) yes, only code reviews should count

Should reviewers for 9.4 get a prize, such as a t-shirt, as a
promotion to increase the number of non-submitter reviewers?

a) yes
b) no
c) yes, but submitters and committers should get it too

Thanks for your feedback!

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Heikki Linnakangas

On 25.06.2013 20:17, Josh Berkus wrote:

Hackers,

I'd like to take a straw poll here on how we should acknowledge
reviewers.  Please answer the below with your thoughts, either on-list
or via private email.

How should reviewers get credited in the release notes?

a) not at all
b) in a single block titled Reviewers for this version at the bottom.
c) on the patch they reviewed, for each patch


a)

Sometimes a reviewer contributes greatly to the patch, revising it and 
rewriting parts of it. At that point, it's not just a review anymore, 
and he/she should be mentioned in the release notes as a co-author.



Should there be a criteria for a creditable review?

a) no, all reviews are worthwhile
b) yes, they have to do more than it compiles
c) yes, only code reviews should count


This is one reason why I answered a) above. I don't want to set a criteria.


Should reviewers for 9.4 get a prize, such as a t-shirt, as a
promotion to increase the number of non-submitter reviewers?

a) yes
b) no
c) yes, but submitters and committers should get it too


a).

I don't think we should make any promises, though. Just arbitrarily send 
a t-shirt when you feel that someone has done a good job reviewing other 
people's patches. And I'm not sure it's really worth the trouble, to 
arrange the logistics etc.


- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Erik Rijkers
On Tue, June 25, 2013 19:17, Josh Berkus wrote:

 How should reviewers get credited in the release notes?
b) in a single block titled Reviewers for this version at the bottom.


  Should there be a criteria for a creditable review?
b) yes, they have to do more than it compiles


 Should reviewers for 9.4 get a prize, such as a t-shirt, as a
 promotion to increase the number of non-submitter reviewers?
b) no



Erik Rijkers



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Andres Freund
On 2013-06-25 10:17:07 -0700, Josh Berkus wrote:
 How should reviewers get credited in the release notes?
 
 a) not at all
 b) in a single block titled Reviewers for this version at the bottom.
 c) on the patch they reviewed, for each patch

b).

If the review was substantial enough the reviewer gets bumped to a
secondary author, just as it already happens.

 Should there be a criteria for a creditable review?
 
 a) no, all reviews are worthwhile
 b) yes, they have to do more than it compiles
 c) yes, only code reviews should count

b). Surely performance reviews should also count, they can be at least
as time consuming as a code review, so c) doesn't seem to make sense.

 Should reviewers for 9.4 get a prize, such as a t-shirt, as a
 promotion to increase the number of non-submitter reviewers?
 
 a) yes
 b) no
 c) yes, but submitters and committers should get it too

Not sure. Seems like it might be a way to spend a lot of effort without
achieving all that much. But I can also imagine that it feels nice and
encourages a casual reviewer/contributor.

So it's either b) or c). Although I'd perhaps exclude regular
contributors to keep the list reasonable?

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Josh Berkus
On 06/25/2013 10:46 AM, Andres Freund wrote:
 Not sure. Seems like it might be a way to spend a lot of effort without
 achieving all that much. But I can also imagine that it feels nice and
 encourages a casual reviewer/contributor.
 
 So it's either b) or c). Although I'd perhaps exclude regular
 contributors to keep the list reasonable?

Well, one of the other prizes which occurred to me today would be a
pgCon lottery.  That is, each review posted by a non-committer would go
in a hat, and in February we would draw one who would get a free
registration and airfare to pgCon.

Seems apropos and without the horrible logistics issues of mailing
tshirts to 15 countries.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Joshua D. Drake


On 06/25/2013 10:17 AM, Josh Berkus wrote:


Hackers,

I'd like to take a straw poll here on how we should acknowledge
reviewers.  Please answer the below with your thoughts, either on-list
or via private email.

How should reviewers get credited in the release notes?

a) not at all
b) in a single block titled Reviewers for this version at the bottom.
c) on the patch they reviewed, for each patch


C. The idea that reviewers are somehow less than authors is rather 
disheartening.




Should there be a criteria for a creditable review?

a) no, all reviews are worthwhile
b) yes, they have to do more than it compiles
c) yes, only code reviews should count


B. I think it compiles, and I tested it via X should be the minimum. 
Here is a case. I was considering taking a review of the new Gin Cache 
patch. I can't really do a code review but I can certainly run 
benchmarking tests before/after and apply the patch etc.




Should reviewers for 9.4 get a prize, such as a t-shirt, as a
promotion to increase the number of non-submitter reviewers?

a) yes
b) no
c) yes, but submitters and committers should get it too

Thanks for your feedback!



B. We already give them a multi-million dollar piece of software for free.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/  509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
For my dreams of your image that blossoms
   a rose in the deeps of my heart. - W.B. Yeats


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Andres Freund
On 2013-06-25 11:04:38 -0700, Joshua D. Drake wrote:
 a) not at all
 b) in a single block titled Reviewers for this version at the bottom.
 c) on the patch they reviewed, for each patch
 
 C. The idea that reviewers are somehow less than authors is rather
 disheartening.

It's not about the reviewers being less. It's a comparison of
effort. The effort for a casual review simply isn't comparable with the
effort spent on developing a nontrivial patch.

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Andrew Dunstan


On 06/25/2013 01:17 PM, Josh Berkus wrote:

Hackers,

I'd like to take a straw poll here on how we should acknowledge
reviewers.  Please answer the below with your thoughts, either on-list
or via private email.

How should reviewers get credited in the release notes?

a) not at all
b) in a single block titled Reviewers for this version at the bottom.
c) on the patch they reviewed, for each patch


b) seems about right.



Should there be a criteria for a creditable review?

a) no, all reviews are worthwhile
b) yes, they have to do more than it compiles
c) yes, only code reviews should count



c). Compilation, functionality and performance tests are useful, but 
what we desperately need are in depth code reviews of large patches. If 
we debase the currency by rewarding things less than that then any 
incentive effect of kudos in encouraging more reviews is lost.





Should reviewers for 9.4 get a prize, such as a t-shirt, as a
promotion to increase the number of non-submitter reviewers?

a) yes
b) no
c) yes, but submitters and committers should get it too



I'd like to see prizes each release for best contribution and best 
reviewer - I've thought for years something like this would be worth 
trying. Committers and core members should not be eligible - this is 
about encouraging new people.


cheers

andrew



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Claudio Freire
On Tue, Jun 25, 2013 at 2:17 PM, Josh Berkus j...@agliodbs.com wrote:
 How should reviewers get credited in the release notes?
 c) on the patch they reviewed, for each patch

This not only makes sense, it also lets people reading release notes
know there's been a review, and how thorough it was. I know, all
changes in PG get reviewed, but having it explicit on release notes I
imagine would be useful. Especially if I know the reviewers.

The co-author part also makes a lot of sense. When a reviewer
introduces changes directly, and they get committed, I think it should
be automatically considered co-authoring the patch.

 Should there be a criteria for a creditable review?

 a) no, all reviews are worthwhile

It's not that they're all worthwhile, but arbitrary decisions lend
themselves to arbitrary criticism. Whatever criteria should be
straightforward, unambiguous and unbiased, and it's hard getting all
those three in any other criteria than: all are worthwhile.

 b) yes, they have to do more than it compiles

This one's better than nothing, if you must have a minimum criteria.
But then people will just point out some trivial stuff and you'd be
tempted to say that trivialities don't count... and you get a snowball
going. IMHO, it's all or nothing.

 Should reviewers for 9.4 get a prize, such as a t-shirt, as a
 promotion to increase the number of non-submitter reviewers?

 b) no

Yeah, while a fun idea, I don't think the logistics of it make it
worth the effort. Too much effort for too little benefit.

And I think recognition is a far better incentive than T-shirts
anyway. I know I'd be encouraged to review patches for the recognition
alone, a lot more than for a T-shirt I might not get. Contributing is
nice, but feeling appreciated while doing so is better.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Josh Berkus
On 06/25/2013 11:26 AM, Andres Freund wrote:
 On 2013-06-25 11:04:38 -0700, Joshua D. Drake wrote:
 a) not at all
 b) in a single block titled Reviewers for this version at the bottom.
 c) on the patch they reviewed, for each patch

 C. The idea that reviewers are somehow less than authors is rather
 disheartening.
 
 It's not about the reviewers being less. It's a comparison of
 effort. The effort for a casual review simply isn't comparable with the
 effort spent on developing a nontrivial patch.

On the other hand, I will point out that we currently have a shortage of
reviewers, and we do NOT have a shortage of patch submitters.  Seems
like we should apply incentives where we need help, no?

Mind you, my votes are (B), (A), and (A).

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Joshua D. Drake


On 06/25/2013 11:26 AM, Andres Freund wrote:


On 2013-06-25 11:04:38 -0700, Joshua D. Drake wrote:

a) not at all
b) in a single block titled Reviewers for this version at the bottom.
c) on the patch they reviewed, for each patch


C. The idea that reviewers are somehow less than authors is rather
disheartening.


It's not about the reviewers being less. It's a comparison of
effort. The effort for a casual review simply isn't comparable with the
effort spent on developing a nontrivial patch.


I think this is a backwards way to look at it.

The effort may not be comparable but the drudgery certainly is.

Reviewing patches sucks. Writing patches (for the most part) is fun.

Should the patch submitter get first billing? Yes.
Should the reviewer that makes sure to a reasonable level that the patch 
is sane also get billing? Absolutely.

Should the reviewer get billing that is about the patch they reviewed. Yes.

As I mentioned before in the release notes something like:

Author: Tom Lane
Reviewer(s): Greg Stark, Andrew Dunstan

I think that is perfectly reasonable.

JD


--
Command Prompt, Inc. - http://www.commandprompt.com/  509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
For my dreams of your image that blossoms
   a rose in the deeps of my heart. - W.B. Yeats


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Dean Rasheed
On 25 June 2013 18:17, Josh Berkus j...@agliodbs.com wrote:
 Hackers,

 I'd like to take a straw poll here on how we should acknowledge
 reviewers.  Please answer the below with your thoughts, either on-list
 or via private email.

 How should reviewers get credited in the release notes?

 a) not at all
 b) in a single block titled Reviewers for this version at the bottom.
 c) on the patch they reviewed, for each patch


b) Unless they contribute enough to the patch to be considered a co-author.


 Should there be a criteria for a creditable review?

 a) no, all reviews are worthwhile
 b) yes, they have to do more than it compiles
 c) yes, only code reviews should count


a) Sometimes even it compiles can be worthwhile, if there is doubt
over platform compatibility. All contributions should be acknowledged
and encouraged.


 Should reviewers for 9.4 get a prize, such as a t-shirt, as a
 promotion to increase the number of non-submitter reviewers?

 a) yes
 b) no
 c) yes, but submitters and committers should get it too


b) Getting your name in the fine manual is reward enough ;-)

Regards,
Dean


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread David Fetter
On Tue, Jun 25, 2013 at 10:17:07AM -0700, Josh Berkus wrote:
 Hackers,
 
 I'd like to take a straw poll here on how we should acknowledge
 reviewers.  Please answer the below with your thoughts, either on-list
 or via private email.
 
 How should reviewers get credited in the release notes?
 
 a) not at all
 b) in a single block titled Reviewers for this version at the bottom.
 c) on the patch they reviewed, for each patch

c)  This keeps history better.

 Should there be a criteria for a creditable review?
 
 a) no, all reviews are worthwhile
 b) yes, they have to do more than it compiles
 c) yes, only code reviews should count

a).  If it turns out that people are gaming this, or appear to be
gaming this, we can revisit the policy.

 Should reviewers for 9.4 get a prize, such as a t-shirt, as a
 promotion to increase the number of non-submitter reviewers?
 
 a) yes
 b) no
 c) yes, but submitters and committers should get it too

b).  You want to be *extremely* careful when paying volunteers.  The
chances of damaging their intrinsic motivations are high, especially
when it's not stuff like covering their expenses.

http://www.iew.uzh.ch/wp/iewwp007.pdf

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread Brendan Jurd
On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote:
 How should reviewers get credited in the release notes?

 a) not at all
 b) in a single block titled Reviewers for this version at the bottom.
 c) on the patch they reviewed, for each patch

A weak preference for (c), with (b) running a close second.  As others
have suggested, a review that leads to significant commitable changes
to the patch should bump the credit to co-authorship.

 Should there be a criteria for a creditable review?

 a) no, all reviews are worthwhile
 b) yes, they have to do more than it compiles
 c) yes, only code reviews should count

(b), the review should at least look at usabililty, doc, and
regression test criteria even if there is no in-depth code analysis.

 Should reviewers for 9.4 get a prize, such as a t-shirt, as a
 promotion to increase the number of non-submitter reviewers?

 a) yes
 b) no
 c) yes, but submitters and committers should get it too

Provisionally (b), if we first try giving proper credit, and that
still doesn't drum up enough reviewing, then look to further incentive
schemes.  No need to jump the gun.

Cheers,
BJ


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Kudos for Reviewers -- straw poll

2013-06-25 Thread David Johnston
Brendan Jurd wrote
 On 26 June 2013 03:17, Josh Berkus lt;

 josh@

 gt; wrote:
 How should reviewers get credited in the release notes?

 a) not at all
 b) in a single block titled Reviewers for this version at the bottom.
 c) on the patch they reviewed, for each patch

I think some consideration toward a commit and review summary (outside the
release notes; and graphical/interactive in nature ideally) for each major
release is something worth considering.  With regards to the release notes
I'd lean toward (b); significant contributions getting bumped to co-author
on specific patches covers (c) fairly well.  I am unsure whether release
note mentions are significant enough motivation...see other thoughts below.


 Should there be a criteria for a creditable review?

 a) no, all reviews are worthwhile
 b) yes, they have to do more than it compiles
 c) yes, only code reviews should count

Ideally (a) though (b) conceptually makes sense but it is too generic.


 Should reviewers for 9.4 get a prize, such as a t-shirt, as a
 promotion to increase the number of non-submitter reviewers?

 a) yes
 b) no
 c) yes, but submitters and committers should get it too

One low-cost prize that I've pondered is, on an ongoing basis, the ability
to post a link and/or message to the PostgreSQL front page within a
significantly less stringent barrier to acceptance than is required for
current content.  Basically except for topics or presentations deemed of
poor taste or detrimental to the project anything should be allowed.  Some
kind of this message was allowed because so-and-so has recently made the
following significant contributions to the project.  There are probably
quite a few logistics to deal with down this path but a sponsor platform for
shameless self-promotion for people making the project successful -
something visible on an ongoing basis and not just once a year in a release
note - is likely a very valuable to the contributor while fairly inexpensive
to the project (i.e., some risk of reputation and some cost to setup the
infrastructure).


David J.





--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Kudos-for-Reviewers-straw-poll-tp5760952p5761031.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers