Re: Adding new committers to OpenRefine repo

[Martin Magdinier]

Moving the discussion to the dev mailing list and bcc previous participant.

Things haven't changed a lot since the 2012 / 2013 transition and we all agree on what needs to be done for OpenRefine (get 2.6 out of the door and have more contributors), what I'd like to do now is doing it.

I submitted a draft governance model a year ago to defined basic rules to achieve such objective, since no organization had a clear ownership of the project anymore (like MetaWeb or Google had). I intentionally left some part undefined to leave room for a discussion. So far it only received vague or no answer (see here, here and here) ; as far as I know no other proposition have been made.

I am all in for Tom plan. What I'd like is to see it formalized in a document we all agree on.

Martin

PS: Based on the apache meritocratic model: the PMC (I guess owner of the OpenRefine repository) approved new committer. This is why I sent the initial request by private email and not to the list.


On 15-04-14 01:36 AM, Stefano Mazzocchi wrote:

+1 to what Tom said.

On Mon, Apr 13, 2015 at 10:32 PM Tom Morris <tfmo...@gmail.com> wrote:

On Mon, Apr 13, 2015 at 5:55 AM, Iain Sproat <iains...@gmail.com> wrote:

I'm not involved much in the project in any active way at present but, and this is a question to all, do we have a policy/procedure for nominating individuals with contribution rights?  My personal thought is that the nomination and consideration process should be open & transparent in line with what the project is trying to achieve.

That's totally in line with my thinking.  I'm not sure why this discussion wasn't on the developer's list to start with.  I'll move it there in the morning (anonymously, of course, since I don't have the sender's permission).

We've got a number of people who have been contributing for years without formal commit privileges and we need to address that.

I think our priorities should be:

- agreeing on and formalizing the procedure to approve new committers (the Apache-style individual meritocracy resonates with me)

- working through the backlog of strong contributors who deserve commit privileges

- attracting strong new candidates to be developed as committers

We'll always have parties, individual or corporate, who want to "enhance" their candidates chances to gain influence and prestige, but I think as long as we have a process firmly grounded in meritocracy, we'll be able to navigate those choppy seas.

Tom

[Thad Guidry]

Martin,

Let's put the draft governance document (or your working document so far) up on our GitHub Wiki so that we can all review it and make comments.  Similar to how you have https://github.com/OpenRefine/OpenRefine/wiki/GSoC-2015-Application

Thad

+ThadGuidry

[Martin Magdinier]

Thad

Thank for your answer.

The draft document is available https://github.com/OpenRefine/openrefine.github.com/blob/master/governance.md
I thought that working with Pull Request and github comment will make the discussion easier vs a wiki

I also just shared some extra thoughts on the importance of clear governance rules.

Martin

[Thad Guidry]

Martin,

Agreed, perfect use of Git and comments.  Thanks for this.

Thad

+ThadGuidry

--
You received this message because you are subscribed to the Google Groups "OpenRefine Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrefine-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Morris]

On Tue, Apr 14, 2015 at 12:09 PM, Martin Magdinier <martin.m...@gmail.com> wrote:

The draft document is available https://github.com/OpenRefine/openrefine.github.com/blob/master/governance.md
I thought that working with Pull Request and github comment will make the discussion easier vs a wiki

I think at this point the organization is too small to need a PMC.  The committers effectively are the PMC.  For nominating new committers openrefine-dev is the right email address to use for right now.  Apache uses a private list for voting discussions and I can see both sides of this.  I guess we could do something similar.  What do people think?  

Here's the Apache new committer process and evaluation critieria: https://community.apache.org/newcommitter.html  I'd propose we use those pretty much unchanged except for any specific Apache-isms.  For voting, the simple Apache style majority +1 and no -1 votes is used by many projects and works for me.  Do folks have other voting systems and/or evaluation critieria that they like?

From a practical point of view, committers actually do have more power/influence/whatever than other contributors right now because they don't have to go through the pull request process.  Now we could change that so all code changes are done through PRs, use Gerrit for code reviews with voting to get PRs approved (and with test coverage & static checkers having votes), but I'm reluctant to add that much overhead to the system (and core committers would probably still have more votes).

Also from a practical point of view, the direction that the project takes is controlled by the contributors, not the users (unless they're contributors too).  While we certainly value our users, the people who are donating their time and money have the right to control how it's used.  If we've got 8 Germans who want a German translation, but none of them want to do it and a single French woman who jumps in and does the translation for her language, guess which language is going to show up in the next kit?

 

I also just shared some extra thoughts on the importance of clear governance rules.

This just isn't the way things work in any open source organization that I'm familiar with (and I've participated in a bunch of them).  If the organization behind RefinePro (RefinePro, Inc.?) wants to start contributing more to the project that would be awesome and we'd welcome it.  If having an extra couple of paragraphs on the web site saying that we're a technical meritocracy and what the voting rules will help encourage that contribution, that's fine.  

However, committer status is something granted based on past performance and current ability, it's not something that's bartered for a possible future contribution.  Here are the contributions made by all contributors to date: https://github.com/OpenRefine/OpenRefine/graphs/contributors  While we might normally have the discussion of a candidates suitability behind closed doors, this isn't a close call, so there's really nothing controversial about it.

We love that Qi has pitched in to help answer questions on the mailing lists, reply to bug reports, and help out in other ways.  We value the three PRs he's submitted, but unless those three PRs were something like three brand new impeccably coded extensions, they wouldn't be anywhere near enough (and even then time and familiarity count too).  One PR changed a 6 to an 8.  Another changed HashMap to LinkedHashMap in two modules.  The last is still pending.

Speaking of the pending PR, in case getting it merged is this is the reason for nominating Qi so early, my current position is that we shouldn't be making major dependency changes (ie Jetty 6 to Jetty 9) before releasing 2.6, so the things that are blocking it are:

- release OpenRefine 2.6

- fix whitespace changes in commit per comment on the PR

- move PR to a feature branch per comment on the PR

We should do a clean sweep upgrading all dependencies, but I don't want to tackle it at the 11th hour and destabilize what we've got.

Tom

p.s. I'll send a follow-up polling people about 2.6, so look for that in your inbox next.

 

[Thad Guidry]

I think at this point the organization is too small to need a PMC.  The committers effectively are the PMC.  For nominating new committers openrefine-dev is the right email address to use for right now.  Apache uses a private list for voting discussions and I can see both sides of this.  I guess we could do something similar.  What do people think?  

Keep nominations public on openrefine-dev list for now.

 

Here's the Apache new committer process and evaluation critieria: https://community.apache.org/newcommitter.html  I'd propose we use those pretty much unchanged except for any specific Apache-isms.  For voting, the simple Apache style majority +1 and no -1 votes is used by many projects and works for me.  Do folks have other voting systems and/or evaluation critieria that they like?

No preference. Apache style voting works for me.

Also from a practical point of view, the direction that the project takes is controlled by the contributors, not the users (unless they're contributors too).  While we certainly value our users, the people who are donating their time and money have the right to control how it's used.  If we've got 8 Germans who want a German translation, but none of them want to do it and a single French woman who jumps in and does the translation for her language, guess which language is going to show up in the next kit?

Cajun, of course.

[Martin Magdinier]

Thanks Tom for your proposition. I agree with most of it. See my answer in line.

On 15-04-16 06:37 PM, Tom Morris wrote:

On Tue, Apr 14, 2015 at 12:09 PM, Martin Magdinier <martin.m...@gmail.com> wrote:

The draft document is available https://github.com/OpenRefine/openrefine.github.com/blob/master/governance.md
I thought that working with Pull Request and github comment will make the discussion easier vs a wiki

I think at this point the organization is too small to need a PMC.  The committers effectively are the PMC.  For nominating new committers openrefine-dev is the right email address to use for right now.  Apache uses a private list for voting discussions and I can see both sides of this.  I guess we could do something similar.  What do people think?  

I don't know how if people mind to be nominated publicly without warning. Happy to have people requesting for nomination  via the openrefine-dev.
However I can't make my mind if the discussion to reach a decision should be public. What I am confident is the motivation of the decision have to be public (the why we accept or reject the nomination).

Here's the Apache new committer process and evaluation critieria: https://community.apache.org/newcommitter.html  I'd propose we use those pretty much unchanged except for any specific Apache-isms. For voting, the simple Apache style majority +1 and no -1 votes is used by many projects and works for me.  Do folks have other voting systems and/or evaluation critieria that they like?

Agree with the +1 / -1 system and evaluation criteria. I'd rather go with a proven system (the apache one) than creating something from scratch.

Do we want to go with the full range of voting option I feel like the +0.9 and -0.9 will bring the nuance for committers with limited time resources.

• ++1: 'Wow! I like this! Let's do it!'
• +1: 'yes'
• +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.'
• +0: 'I don't feel strongly about it, but I'm okay with this.'
• -0: 'I won't get in the way, but I'd rather we didn't do this.'
• -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.'
• -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.'
• -1 'no' and vetos on a code modification. vetos must be accompanied by a technical justification showing why the change is bad

in bold an smaller subset of vote option as describe here.

From a practical point of view, committers actually do have more power/influence/whatever than other contributors right now because they don't have to go through the pull request process.  Now we could change that so all code changes are done through PRs, use Gerrit for code reviews with voting to get PRs approved (and with test coverage & static checkers having votes), but I'm reluctant to add that much overhead to the system (and core committers would probably still have more votes).

So far the volume is low enough (one a week max). Can we do the voting in the pull request comment section in github?
We can set the same voting system in Github issue comment to see what people want to see next (or not).

Also from a practical point of view, the direction that the project takes is controlled by the contributors, not the users (unless they're contributors too).  While we certainly value our users, the people who are donating their time and money have the right to control how it's used.  If we've got 8 Germans who want a German translation, but none of them want to do it and a single French woman who jumps in and does the translation for her language, guess which language is going to show up in the next kit?

agree

 

I also just shared some extra thoughts on the importance of clear governance rules.

This just isn't the way things work in any open source organization that I'm familiar with (and I've participated in a bunch of them).  If the organization behind RefinePro (RefinePro, Inc.?) wants to start contributing more to the project that would be awesome and we'd welcome it.  If having an extra couple of paragraphs on the web site saying that we're a technical meritocracy and what the voting rules will help encourage that contribution, that's fine.  

IMO we can't assume that every developer willing to contribute to OpenRefine is familiar on how open source project works. Having the rules easy to access and clearly stated will help new comers to interact with the community.

However, committer status is something granted based on past performance and current ability, it's not something that's bartered for a possible future contribution.  Here are the contributions made by all contributors to date: https://github.com/OpenRefine/OpenRefine/graphs/contributors  While we might normally have the discussion of a candidates suitability behind closed doors, this isn't a close call, so there's really nothing controversial about it.

Don't get me wrong, I 100% agree that committer status should be granted on past performance and current ability. Knowing exactly how we decide on performance and ability (as defined in the apache new committer guide) help new contributors to know what to expect if they send a PR or request committers access.

[Martin Magdinier]

I've edited the governance document with Tom and Thad feedbacks: https://github.com/OpenRefine/openrefine.github.com/blob/master/governance.md

Next Steps:

1. If the community is OK to go with those rules, I will make them accessible via the website and add a reference in the README of OpenRefine.
2. Invite long time contributors to become committer via this mailing list.
   

Martin

On 15-04-16 06:37 PM, Tom Morris wrote:

[Martin Magdinier]

for archive

---------- Forwarded message ----------
From: Iain Sproat <iains...@gmail.com>
Date: 2015-04-13 5:55 GMT-04:00
Subject: Re: Adding new committers to OpenRefine repo
To: Martin Magdinier <martin.m...@gmail.com>, Thad Guidry <thadg...@gmail.com>, Tom Morris <tfmo...@gmail.com>
Cc: "Qi (Jacky) Cui" <cuiq...@gmail.com>, David Huynh <dfh...@gmail.com>, stef...@google.com

Martin,

It's extremely exciting to see commercial development on top of OpenRefine, and particularly encouraging to see the contributions you are returning to the community.

I'm not involved much in the project in any active way at present but, and this is a question to all, do we have a policy/procedure for nominating individuals with contribution rights?  My personal thought is that the nomination and consideration process should be open & transparent in line with what the project is trying to achieve.

Iain

On Mon, 13 Apr 2015 at 08:17 Martin Magdinier <martin.m...@gmail.com> wrote:

Tom, Thad,
(cc David, Stefano, Iain and Qi)

At RefinePro we are nearly done building our MVP for hosted instance of Refine and we are in the process of landing out first on-premise customer. For the last 6 months our focus was on migrating Refine as a cloud application and take care of all the extra other things you have to do when starting a new business.

Today with Qi, we are looking at contributing more to the OpenRefine project and help with the release of the next version while looking at developing new feature. In part of this process I'd like to propose Qi as a new committer to the OpenRefine project.

In the last three months, Qi has been working on updating jdk and the Refine dependency while tracking some javascript error and providing regular support to the user on the discussion list and repository. He also explored in details what has been done with SparkRefine and python library. Based on RefinePro's beta user feedback and the mailing list archive, he developed a clear vision for OpenRefine core that he will be sharing later this month (our current focus is still on delivering our first customer). As RefinePro technical co-founder, Qi is invested on the long term on OpenRefine technology.

Looking forward for your feedback and happy to move this discussion to the developer mailing list.

Martin

[Martin Magdinier]

---------- Forwarded message ----------
From: Martin Magdinier <martin.m...@gmail.com>
Date: 2015-04-14 11:51 GMT-04:00
Subject: Re: Adding new committers to OpenRefine repo

[Martin Magdinier]

---------- Forwarded message ----------
From: Tom Morris <tfmo...@gmail.com>
Date: 2015-04-16 18:37 GMT-04:00
Subject: Re: Adding new committers to OpenRefine repo
To: openref...@googlegroups.com

To unsubscribe from this group and stop receiving emails from it, send an email to openrefine-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenRefine Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openrefine-dev+unsubscribe@googlegroups.com.

[Martin Magdinier]

---------- Forwarded message ----------
From: Martin Magdinier <martin.m...@gmail.com>
Date: 2015-04-16 19:42 GMT-04:00
Subject: Re: Adding new committers to OpenRefine repo
To: openref...@googlegroups.com

To unsubscribe from this group and stop receiving emails from it, send an email to openrefine-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenRefine Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openrefine-dev+unsubscribe@googlegroups.com.