A question was asked on Gitter here where:
@GeertvanHorrik said...
Thanks @patriksvensson . I was just wondering how you deal with this. Maybe it's good to ask community people to contribute to a centralized repository so others can take over if need be?
This was basically in response to an attempt that was being made to change an existing Cake Addin, when the maintainer of said Addin seemed to be not available. In this particular example, the maintainer came back very quickly, and the issue was resolved, but it does raise the question about what happens when a maintainer does step away from an Addin, what do we do?
What follows is my recommendations for how to deal with this situation (based on conversations with @devlead @patriksvensson and @Redth) and I was hoping to get some feedback from the wider community on how to proceed.
Example Situation that we want to avoid
The imagine the following situation as our example...
A Cake Community Member creates a new addin for Cake (hosting the code in his/her own repository), then pushes it to NuGet.org using their own account. Life then gets in the way, and that maintainer of the package isn't able to respond to issues, pull requests, any more. Another community member takes it upon themselves to fork the repo, implement the required changes and suggestions, and pushes essentially a duplicate package to NuGet.org
What is wrong with this from a maintainability stand point
- Essentially duplicate packages on NuGet.org, so people are not sure which one to use
- Duplicate code bases, again, which one should be used
Possible solutions to this problem
- The creator of the original addin could make other people contributors/owners of the repo in question, and essentially allow them to take over the package
- The creator of the original addin could add additional maintainers to the package on NuGet.org
Both of these solutions would fix both of the issues mentioned above, however, I am not sure if it goes far enough. Both of these solutions would require after the fact changes to allow people access to both the repo and NuGet.org. Both of which might not be possible. i.e. if the original maintainer isn't responding to issues/pr's, they might not be available to provide access to the systems either.
A potential solution
I am going to suggest that we create a new Organisation on GitHub (let's call it Cake-Contrib). We would invite all existing Addin creators (and obviously new addin creators) to put their Addin Repositories into this organisation. Within the organisation we would create a team for each addin. This team would consist of all Core Cake Team members as well as the addin creator. This team would have full access to the repo once under the organisation.
In addition, the addin creator would add the cake-build NuGet user as a co-maintainer of the package on NuGet.org.
With these two things in place, we solve both the problems described above.
- Code is always in one place, and if issues/pr's are starting to get missed the Cake Core Team members to step in to help out
- The cake-build NuGet user has access to push a new version of the package, no again, no duplicates
Following on from this, I would see other teams being added to the Cake-Contrib repo. These would be teams of trusted Addin Creators, who are given access to repos other than their own, as they have proven to be very good at what they do, and can help out where necessary.
Important points
- The original addin creator would still have full access to the repo under the new organisation
- They would still be responsible for the day to day maintenance of the addin. Other team members would only step in when things aren't being dealt with
Minimum things to be included in order to get acceptance into organisation
- Documentation for Addin
- Unit Tests
- CI builds
- Anything else?
Idea that was suggested and discarded
A single repository which housed all the addins. This was discarded as it didn't allow enough control over who has access to individual sections of the repo. i.e. there are no folder based permissions in GitHub. As a result, the security control wasn't granular enough.
A question was asked on Gitter here where:
This was basically in response to an attempt that was being made to change an existing Cake Addin, when the maintainer of said Addin seemed to be not available. In this particular example, the maintainer came back very quickly, and the issue was resolved, but it does raise the question about what happens when a maintainer does step away from an Addin, what do we do?
What follows is my recommendations for how to deal with this situation (based on conversations with @devlead @patriksvensson and @Redth) and I was hoping to get some feedback from the wider community on how to proceed.
Example Situation that we want to avoid
The imagine the following situation as our example...
A Cake Community Member creates a new addin for Cake (hosting the code in his/her own repository), then pushes it to NuGet.org using their own account. Life then gets in the way, and that maintainer of the package isn't able to respond to issues, pull requests, any more. Another community member takes it upon themselves to fork the repo, implement the required changes and suggestions, and pushes essentially a duplicate package to NuGet.org
What is wrong with this from a maintainability stand point
Possible solutions to this problem
Both of these solutions would fix both of the issues mentioned above, however, I am not sure if it goes far enough. Both of these solutions would require after the fact changes to allow people access to both the repo and NuGet.org. Both of which might not be possible. i.e. if the original maintainer isn't responding to issues/pr's, they might not be available to provide access to the systems either.
A potential solution
I am going to suggest that we create a new Organisation on GitHub (let's call it Cake-Contrib). We would invite all existing Addin creators (and obviously new addin creators) to put their Addin Repositories into this organisation. Within the organisation we would create a team for each addin. This team would consist of all Core Cake Team members as well as the addin creator. This team would have full access to the repo once under the organisation.
In addition, the addin creator would add the cake-build NuGet user as a co-maintainer of the package on NuGet.org.
With these two things in place, we solve both the problems described above.
Following on from this, I would see other teams being added to the Cake-Contrib repo. These would be teams of trusted Addin Creators, who are given access to repos other than their own, as they have proven to be very good at what they do, and can help out where necessary.
Important points
Minimum things to be included in order to get acceptance into organisation
Idea that was suggested and discarded
A single repository which housed all the addins. This was discarded as it didn't allow enough control over who has access to individual sections of the repo. i.e. there are no folder based permissions in GitHub. As a result, the security control wasn't granular enough.