Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

call for maintainer #131

Open
suhailshergill opened this issue Feb 9, 2019 · 15 comments
Open

call for maintainer #131

suhailshergill opened this issue Feb 9, 2019 · 15 comments

Comments

@suhailshergill
Copy link
Owner

Hello all, over the next few months I might not be in a position to be an active maintainer (due to personal reasons). I would like to ensure that in the meanwhile there is minimal effect on the library. Specifically, bug-fixes and updates get pushed in a timely manner.

Could someone volunteer to be an additional maintainer? Shout out to @greydot @mattaudesse @sheyll, @power-fungus

Thanks

@greydot
Copy link
Collaborator

greydot commented Feb 9, 2019

Sure, I could try.

@suhailshergill
Copy link
Owner Author

Thanks @greydot !

@suhailshergill
Copy link
Owner Author

@greydot I've invited you to have push access to the repo. Would you like to test that with a commit to add yourself to the maintainer list in the cabal file? Once we've confirmed that github permissions are working ok, we can then sort the hackage permissions.

@sheyll
Copy link
Collaborator

sheyll commented Feb 10, 2019

I am also available :)

@suhailshergill
Copy link
Owner Author

@sheyll thanks! I'm not very knowledgeable of github's options. Would it make things easier to transition to an organization/team setup? Do you have thoughts?

@sheyll
Copy link
Collaborator

sheyll commented Feb 11, 2019

I have just read in the github help about the two obvious options:

  1. inviting collaborators to a project
  2. managing access via "Organizations".

The former option is a quick and easy way to invite someone to a single repository.

But as soon as more than a single repository needs to be managed,
"organizations" seem to reduce the amount of work to manage permissions: Repository permission levels for an organization

Organizations assign multiple repositories to multiple users; organization members are assigned to one of three roles governing access permissions to all repositories.

Compared to the first option they don't have to be invited to collaborate on every new repository.

So multiple repositories are easier managed through an organization, and it makes sense to establish an organization for extensible-effects, if this library will ever be split into multiple strongly related, yet independently released, source repositories.

@greydot
Copy link
Collaborator

greydot commented Feb 11, 2019

@greydot I've invited you to have push access to the repo. Would you like to test that with a commit to add yourself to the maintainer list in the cabal file? Once we've confirmed that github permissions are working ok, we can then sort the hackage permissions.

I wasn't able to push to this repo.

> git push       
ERROR: Permission to suhailshergill/extensible-effects.git denied to greydot.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

UPD: disregard this, all sorted out.

@suhailshergill
Copy link
Owner Author

it makes sense to establish an organization for extensible-effects, if this library will ever be split into multiple strongly related, yet independently released, source repositories.

that is an interesting point and one i have considered in the past. specifically, the polymorphic variants (i.e., OpenUnion) could potentially be a standalone library. but so far there hasn't been a compelling need to split them up.

if i'm understanding the organization roles (thanks for sharing the link btw), another feature that organizations seem to provide is that of an admin role. i believe "collaborators" correspond to write access. and so collaborators wouldn't have the ability to add/remove other collaborators (which may something we may want to have if i'm going to be away for an extended period).

@sheyll
Copy link
Collaborator

sheyll commented Feb 12, 2019

I believe that only owners can add or remove members, the admin role is for repo administration like, archiving and renaming.

@suhailshergill
Copy link
Owner Author

suhailshergill commented Feb 13, 2019

I believe that only owners can add or remove members, the admin role is for repo administration like, archiving and renaming.

not quite. per the link you shared, the below is one of the abilities that admin roles have:

Add outside collaborators to a repository (see "Adding outside collaborators to repositories in your organization" for details)

similarly

Remove outside collaborators from a repository

@sheyll
Copy link
Collaborator

sheyll commented Feb 14, 2019

Thanks for clarifying.

@suhailshergill
Copy link
Owner Author

for convenience i've decided to stick with adding collaborators (creating an organization seems a tad overkill at present). @greydot , @sheyll would you like to add your names to the maintainers list in cabal file?
btw, do you have an accounts on hackage already?

@sheyll
Copy link
Collaborator

sheyll commented Feb 19, 2019

First of all, thank you.

I do have a hackage account: SvenHeyll

@greydot
Copy link
Collaborator

greydot commented Feb 21, 2019

@suhailshergill sickmind

@suhailshergill
Copy link
Owner Author

@sheyll @greydot i've added your names to hackage maintainer list: https://hackage.haskell.org/package/extensible-effects/maintainers/
is there anything else that we need to cover that i've missed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants