On Tuesday, August 22, 2017 5:24:40 AM CEST Ray Satiro via curl-library wrote:
> On 8/21/2017 5:09 AM, Daniel Stenberg wrote:
> > Starting now, I will remove idling owners and collaborators on github.
> > People who haven't commented anything, sent an email to any curl list
> > or done a commit to a repository during the last 18 months will be
> > deemed "inactive" and will be removed from the owners team. I don't
> > have any automated system for this so I ponder I'll just check it
> > manually like every 6 months or so.
> >
> > So now we're 21 owners.
>
> You could have called for feedback first. I think we had a similar
> conversation a year ago :) As of now there are 21 collaborators that by
> default can write (clone/push/pull). 4 collaborators are Owners now and
> since last year: You, Dan, Steve, Me. The other collaborators are
> Members, which have different permissions. In your panel you should not
> see or have seen any more than 4 Owners, if you do it's a bug and you
> should contact github.
>
> Members may or may not have admin privileges for some repository. As
> things stand now no Member has admin privileges on curl/curl or
> curl/curl-www, ie they can't delete them. If they had admin status for a
> repo they could delete just that repository since that option is enabled
> [1]. I don't know what happens if Member X creates repo curl/Y but it's
> possible they receive admin access for that repo since they created it,
> which means with the default settings they could also delete that repo.
>
> What we could do is change the default permissions from Write to None,
> add everyone that's currently a Member to write curl/curl, and then
> after 1 year (or 6 months.. whatever :) if they don't have any commits
> then remove the write access and send a polite e-mail explaining that
> they are still Members but write access was removed due to inactivity. I
> think this is better than wholesale removing? them. This would likely
> eventually transform Members into more of an alumni (congratulations:
> you've graduated curl college) instead of being based on activity.
> Activity would determine permissions but not membership. I'm not 100%
> sure of no pitfalls, but what do you think of this idea?

You are proposing an alternative approach but it is not immediately obvious
what the advantages over Daniel's approach are. Could you please summarize
which practical benefits it would bring?

Is it just that former contributors would feel less bad with removed
permissions compared to removed membership?

If that is the case, then I really do not care myself. Historical data
about past contributions are kept in git history, so it could potentially
survive longer than anything specific to Github. And no, I do not need
to be listed as an active member of the curl development team after few
years of inactivity...

Kamil

> [1]: https://github.com/organizations/curl/settings/member_privileges
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-08-22