Thanks for the feedback and questions!
I’m typing these replies in the way I currently imagine things working, so please let me know if you think I’m heading in the wrong direction.
what if a library is not on github (gitlab, darcsden, etc.)? Would this process accomodate those too?
I think it would be simpler to manage if everything was in the same place, and it is possible to copy repositories into the organization if it’s not available in another github account. But I imagine that we would want some index of the packages we manage and I don’t see any blockers from referencing alternative VCS hosting platforms. In the beginning it may make sense to focus just on github and if the HP takes off and there is demand, then we can evaluate other platforms to see how we could administer them in a similar fashion.
Would the maintainers be work “per package”? Would there be “haskell party general” folks (handling relatively straightforward commits like dependency bumps etc.)?
Maintainers would work per package. I think having these general maintainers would be good. This could start out as an informal process where such a volunteer can simply apply to help maintain some of the packages. I’m hoping that we could be very permissive in adding more maintainers to these projects, but that would be up to the maintainers of the project in question. I would like to avoid having only a few people do most of the work as that makes one person leaving a high risk.
This could also be an opt-in when joining: Do you want to allow Generals to make simple patches ala NMUs?
would this include evaluating merge requests (stuff more complex than a simple dependency bump)?
I think this is pretty hard to do. Even if I was granted access a proper maintainer of an existing library, I would be hesitant to do complex changes without taking the time to understand the project and the impact. I think this is best left for the maintainers.
how would HP handle maintainers inactivity?
I was vague on this, but I imagined there would be some periodical check-in to see if the maintainers are still around by checking github activity (are there simple PRs that go unmerged?) and perhaps asking if the listed maintainers still consider themselves active.
If the maintainers cannot be reached then we would do a callout for new maintainers.
It’s good that you bring this up because I think we need to specify how this will work in more detail before we launch. This process should be simpler and quicker than package takeovers, but I’m not sure how aggressive we should be.
