ProjectPythia / .github

Community health files: Contributing guidelines, Code of Conduct, ...
Apache License 2.0
2 stars 4 forks source link

Clarify cookbook transfer process in Contributor's Guide #40

Closed r-ford closed 1 year ago

r-ford commented 1 year ago

Section 4i currently reads

  1. Transfer cookbook to the ProjectPythia organization

    1. Navigate to the settings of your repo, scroll down to the Danger Zone, and click "Transfer"
      1. For ProjectPythia owners or members: type "ProjectPythia", confirm, and transfer
      2. For outside contributors:
        1. Contact an owner of ProjectPythia to be added as an outside collaborator. Then transfer to ProjectPythia; or
        2. Type the username of an owner or member. They will then tranfer it to ProjectPythia and add you as an outside collaborator on that repo

I think our current process would look something like

  1. Contact Project Pythia via the Pangeo Discourse (or otherwise) to let us know about your Cookbook
  2. Someone will add you as a member of the ProjectPythia org
  3. Transfer your Cookbook to the ProjectPythia org
  4. Your role will be changed to "Outside collaborator" so that you will still have write access to your Cookbook

This might be a slightly awkward way of doing it, since it involves adding someone as a full member before "demoting" them, but I'm not sure if there is a more straightforward way. Our base permissions for members is read-only, so we may not even need to demote to outside collaborator. @dcamron Does this make sense based on your experience so far?

brian-rose commented 1 year ago

My $0.02: we should completely get rid of the "outside contributor" status. It's not necessary and puts up an unhelpful silo around Pythia.

If you contribute something, you should be a member of the Pythia org.

We can and do use GitHub teams for more fine-grained control of access, review requests, etc.

dcamron commented 1 year ago

Yep, that's what I've done for two contributions so far. "Demoting" to outside collaborator is limiting in some ways (eg repo settings) and may not be necessary, though it might make it easier to manage contributor access (and see the list of those) as we grow. Either way we should probably also add this as a step to the issue template in cookbook-gallery.

edit: a cookbook-contributor team or something could balance the organizational value with reducing the demotion headache.

r-ford commented 1 year ago

I think it makes sense to abandon the outside collaborator role and use teams to organize permissions. It would be worth discussing the specifics at our next meeting, but for now I'll open a PR to reflect our current process without the demotion part (steps 1-3 above).

brian-rose commented 1 year ago

I may be absent from our next meeting, but my strong opinion is that we need to build a big tent. Making a habit of "demoting" people sends the wrong message. We need to be as inclusive as possible in our practices.

conda-forge uses a teams model to manage access. I'm a member of the (very large) conda-forge organization, which costs nothing but gives me a sense of inclusion. And I'm a team member on the small handful of repos that I'm a named maintainer of. I only have merge credentials on those repos. I think this model works well.