Contributors with privileges and special subject areas (spin-off of Re: Project Merge criteria)

[Pierre Smits <pi...@gmail.com>]

Let us not overcomplicate the process unnecessarily by creating the need
for subject matter expert who can then become committers at this stage of
becoming an Apache top level project.

The generic ASF assertion regarding contributions in relation to achieving
privileges can be summed up to:

   1. All contributions are equal;
   2. Contributions buys privileges

See slides 27 & 28 of this
http://www.slideshare.net/gagravarr/the-apache-way-apachecon-2014, or here
http://events.linuxfoundation.org/sites/events/files/slides/TheApacheWay14.pdf

Currently this podling is to small to have us spend time on this, because
every differentiation in roles/hats needs to be described together with the
responsibilities and expectations in our wiki pages and that needs to be
agreed upon.

Why don't you start with nominating contributors for getting privileges as
soon as any of you see them contributing and see them to be willing to
register an iCLA with the secretary. And have the appropriate officers
onboard them.

No podling or project can have to many contributors with commit privileges.
As soon as you have plenty specialisation will kick in, but before that the
commit burden can be shared among the many in stead of the few.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Jul 8, 2015 at 1:36 AM, Hans Zeller <ha...@esgyn.com> wrote:

> Hi Suresh,
>
> IMHO we need to add more committers, so that the group of committers has
> the needed expertise and we don't overload the existing ones. If someone's
> expertise is needed enough times for review, then in a meritocracy that
> means that the person should be made a committer. I think it will be good
> for Trafodion if people want to be committers and if the community feels
> that committers are chosen based on their level of contribution.
>
> Also, there is probably not a good way to get around some special authority
> for committers. Even in your proposal, the committers' authority to choose
> subject area experts is special. So, I do think that the committers should
> have veto authority, within reason, like they do in other Apache projects.
> I don't remember any abuses of that power in Trafodion.
>
> My intent is to propose a model that's somewhat similar to what we see in
> HBase.
>
> Thanks,
>
> Hans
>
> Hans
>
> On Tue, Jul 7, 2015 at 2:45 PM, Suresh Subbiah <suresh.subbiah60@gmail.com
> >
> wrote:
>
> > Hi All,
> >
> > This message is to revive a thread started by Steve and Alice on project
> > merge criteria.
> >
> > Please add your input here, there have been excellent suggestions by
> > Pierre/others on how JIRA can be used and when in the dev cycle reviews
> > should be done.
> >
> > I would personally prefer a model where a committer did not have special
> > authority on vetoing changes but instead helps choose subject area
> experts
> > for review. The opinions of those reviewers are then binding. Once
> > sufficient information has been collected in an email thread I can
> collate
> > it into a proposal we can DISCUSS/VOTE.
> >
> > Thanks
> > Suresh
> >
> >
> > I think the existing tests are sufficient for fixing the current bugs.
> > My question is what
> > about new features?  The current tests do not cover those.
> > Personally, I think new tests
> > (or instructions on how to verify the feature) should accompany new
> > features even if the new
> > tests are not fully automated yet.  Otherwise how are we supposed to
> > verify these new features?
> >
> > Cheers,
> > Alice
> >
> >
> > -----Original Message-----
> > From: Varnau, Steve (Trafodion)
> > Sent: Thursday, June 18, 2015 1:50 PM
> > To: dev@trafodion.incubator.apache.org
> > Subject: Project merge criteria
> >
> > While we're waiting for the software grant process, perhaps the
> > committers should discuss
> > the criteria for accepting and merging in code
> > changes.
> >
> https://wiki.trafodion.org/wiki/index.php/Committer_Workflow#Ensure_Criteria_are_Met
> >
> > I've set up automated testing to run the same test suites as we ran
> > before for core changes
> > in the zuul "check". (There is no automated "gate" test.) Assuming
> > that is the same, then
> > the other non-test criteria are open for discussion I think.
> >
> > -Steve
> >
>