Benjamin Kowarsch:
On Sun, 24 Mar 2024 at
09:28, Alice Osako wrote:
I don't
especially want to step on the toes of Benjamin Kowarsch
and his colleagues, but I think it in addition to what
I've already done with CardBitOps library, might be
worth the trouble to hoist several other elements of the
M2BSK library to separate projects, to make it easier to
apply them to other projects beyond both M2BSK itself
and those I am already working on.
The code is published open source in a public repository
precisely so that other people can benefit from it.
I don't suggest
this lightly, if for no other reason than that it puts
me in the position of being the key figure in
maintaining several libraries. However, I suspect that
others would benefit from doing this.
<snip>
I can move the code out into a separate repository and
give anyone who wants to contribute write access. This would
probably be better than forking it. Also, nobody will then
have to worry about taking on responsibility for the repo.
People can just contribute on an ad-hoc basis.
Hoisting these modules to a separate repo en masse would make a
great deal of sense. Please do so if you if you have the chance.
Thank you for offering to do so.
I'm not sure if keeping it as an open repo is the best solution, as
it is more typical in Git projects that each contributor forks the
project and issues pull requests when ready; while this does require
an active maintainer, it would ensure that merge conflicts are
suitably resolved. It also means that the maintainer wouldn't need
to explicitly allow individual contributors access to the main repo,
as anyone could fork the project, make their changes, and then issue
pull requests, which the maintainer could then review for
suitability.
It also means that individual contributors can have private branches
of the trunk, for experimental changes and additions, then merge
them to their local trunk and issue a pull request with just the
modified trunk, rather than exposing all of the various temporary
branches.
Finally, an open repo does run the risk of someone vandalizing the
repo, though it is unlikely as each contributor would presumably be
vetted by the maintainer.
Either way, there would still be a need for someone to actively
maintain the project.
However, this is your choice, and I expect that you already know the
practicalities of each approach. It should work well enough in any
case - I don't expect that there would be a lot of concurrent edits
to merge, nor would I expect anyone to bother trying to vandalize
the repo.