Jakub, 

This is a good formalization of the existing process. In particular, the notion that access is determined by association with a team, rather than on an individual basis, is important as it substantially simplifies how we handle people leaving a team. 

Zak

On Mon, Jul 23, 2018 at 7:07 AM Jakub Skoczen <jakub@indexdata.com> wrote:
Yes. I think direct write access should be limited to active FOLIO developers that are associated with particular teams (Core, EBSCO/FS, Stacks, EPAM, etc) and further limited on a project by project basis. This is close to what exists already but I don't think it has ever been formalized. I would propose the following formulation:

1. John (or a group of admins) sets up GitHub groups for each team (folio-core, folio-stacks, folio-ebsco, etc) and grants write access to particular repositories (okapi, stripes-core, mod-acquistions, et) on a group basis. Generally, it would be preferable if John did not have to provide access to individual developers.

2. Group membership for individual team members is at the team's lead/PO/PM discretion. Request about removing or adding particular members to a selected group is sent to John.

3. Individual FOLIO contributors (unaffiliated) would follow the fork-then-pull-request model and are not granted direct write privileges to any repositories.  

Comments?

On Fri, Jul 20, 2018 at 7:08 PM Tod Olson <tod@uchicago.edu> wrote:
I think direct write access needs to be considered closely. I don't think it necessarily needs to be some directly affiliated with one of the three current stakeholders, but I cannot right now imagine who else would have the commitment to FOLIO and demonstrated responsibility that would would merit write access. In my mind it comes back to the code stewardship question.

-Tod

On Jul 19, 2018, at 1:59 PM, Michael Gunning <mgunning@ebsco.com> wrote:

I think that sounds right but before we do that and set a precedent I just want to ask couple questions. 

1 - will this be the same for everyone who leaves the project? If so good if not then pls help me draw the distinction. 

Some concrete examples may help:
  - Zev is leaving ID is he handled same way?
  - what if a library takes one of their devs off the project, let’s say Jeremy got another assignment for a while for example, would it be the same?
  - what if an Ebsco developer stays with Ebsco but is reassigned to a different project? 

And 2 - is there a process for someone who wants direct write access and not directly affiliated with ID, ebsco, or ole to get direct write access?

Thanks!

Mike Gunning
Mobile: 520-429-1661

On Jul 19, 2018, at 7:13 AM, Jakub Skoczen <jakub@indexdata.com> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

We should revoke his membership in groups that have direct write access to FOLIO repos. He is of course welcome to continue contributing through a standard GH model (fork + PR). Do you know his nickname?

On Wed, Jul 18, 2018 at 4:29 PM Mark Veksler <mveksler@ebsco.com> wrote:
sort of a last minute request... but ( could we also talk about what to do with terminated employees who worked on FOLIO and have github access.  SHould it be revoked or not? Scratching my head since its an open source project and, in theory, they should retain their access whether they are terminated or not?
In case you're wondering, it was a Frontside employee who was terminated.


On 7/18/18, 10:04 AM, "tech-council@ole-lists.openlibraryfoundation.org on behalf of Mike Gorrell" <tech-council@ole-lists.openlibraryfoundation.org on behalf of mdg@indexdata.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


    Please see today’s agenda. We won’t have Jakub in attendance, FYI.

    https://wiki.folio.org/display/TC/20180718+-+July+18%2C+2018+-+Technical+Council+Meeting+Notes

    -mdg

    To unsubscribe from this list please go to http://archives.simplelists.com


To unsubscribe from this list please go to http://archives.simplelists.com


--
--
Regards,
Jakub Skoczen

To unsubscribe from this list please go to http://archives.simplelists.com

To unsubscribe from this list please go to http://archives.simplelists.com


To unsubscribe from this list please go to http://archives.simplelists.com



--
--
Regards,
Jakub Skoczen

To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=ziEpDIpEAdOqeytbJdCltsFABsHplgyC