call for maintainer
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
Sure, I could try.
Thanks @greydot !
@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 am also available :)
@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?
I have just read in the github help about the two obvious options:
- inviting collaborators to a project
- 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 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.
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).
I believe that only owners can add or remove members, the admin role is for repo administration like, archiving and renaming.
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
Thanks for clarifying.
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?
@suhailshergill sickmind
@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?