[Gt-eos] Determining project collaboration and ownership

[Mischa Salle]

Hi all,

just to mention that I fully agree with BrianB's suggested model!
Especially since we take over a chunk of existing code with a diverse
group of developers, I think such a model makes a lot of sense: each
person can devote some time when it is suitable, but will not be the
sole responsible at times that it might be very difficult. 
Also I'm not sure whether rotating the release manager is really needed:
if there is sufficient agreement, it can also be shared by a small but
fixed group of people.

I would suggest to start setting up a github organization as soon as
possible, and then fork the globus toolkit repo into it. After that we
can start adding relevant (development) people to the organization.

Mischa

On Fri, Oct 20, 2017 at 09:35:51AM -0500, Brian Bockelman wrote:
> 
> > On Oct 20, 2017, at 7:32 AM, Frank Scheiner <scheiner at hlrs.de> wrote:
> > 
> >> For all the shared items we'll need to decide on the ownership model. Here are some ideas:
> >> - Single-owner: there has been a suggestion where the "owner" of
> >> the piece of software would rotate amongst the various orgs where
> >> the "owner" would be responsible for support, development, and
> >> releases. We'd have to have some sort of system in place for
> >> critical/intensive issues where other organizations could be called
> >> on for assistance.
> >> - Multi-owner model: Since I imagine most issues will originate
> >> from within each orgs already established support channels, the org
> >> that gets the issue owns the development for it (with the ability
> >> to pull in other orgs for critical/intensive issues). Then the
> >> development, testing, and release all have to be signed off by each
> >> collaborative organization.
> >> - Some combination of the above
> >> - Something else entirely
> > 
> > I'd prefer the Multi-owner model, because if an organization that is
> > the single owner of a piece of software leaves for some reason
> > (missing funds, missing manpower, etc.) we'd have a similar
> > situation than now with Globus, although on a smaller scale. With
> > the multi-owner model, multiple organizations can build up expertise
> > on a single piece of software, which makes it less of a problem if
> > an organization leaves.
> > 
> 
> I would suggest something along the lines of how Apache projects work.
> 
> - All contributions go through the GitHub PR workflow.
> - Prior to merge, pull requests must have an approved review by a project committer and no rejections.
>   - We can setup a "code owners" page in GitHub such as https://github.com/root-project/root/blob/master/.github/CODEOWNERS <https://github.com/root-project/root/blob/master/.github/CODEOWNERS>.  GitHub will *suggest* reviewers based on the contents of the file, but I suggest we *do not require* the owner to be the reviewer.  We will have a very tiny amount of effort for this; it'd be better to not create too much friction.
> - There is a person who acts as a "release manager" for each release.  This person will do all the preparation for a release (create pre-release tags, tarballs, review results of automated tests, etc) and put the release candidate up for a vote.
>   - This is the part that can rotate between volunteers.
>   - Prior to tagging a final release, the release manager calls a vote of the committers.  Voting styles vary, but one example would be to require 3 positive votes for a release and a majority positive.
>     - I find the Apache "meritocracy model" useful here.  Individuals are on the PMC and can vote, not organizations.
> 
> Basically - it allows lots of people to contribute easily, but has a single person for getting a release out the door.
> 
> Again, let's not overthink it.  This isn't a 10FTE project.  I'd be tickled if it was a 1 FTE project split over 5 people (but I'm not that optimistic...).  Look at the git repo history -- there's not an immense amount of active maintenance needed here.
> 
> Brian
> 

> _______________________________________________
> Gt-eos mailing list
> Gt-eos at mailman.egi.eu
> http://mailman.egi.eu/mailman/listinfo/gt-eos


-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3402 bytes
Desc: not available
URL: <http://mailman.egi.eu/pipermail/gt-eos/attachments/20171022/cec43a01/attachment.p7s>