I would strongly recommend *against* closing the issue tracker. If you had done so before, I wouldn’t have been able to submit *any* of the issues that I had. Don’t stand in the way of well meaning people who want to make contributions. :)
I’m not a lawyer, but I’ve dealt with this in other venues. In software, generally, reported issues in a public tracker like this are considered contributions, and not all contributions covered by whatever licensing the codebase has. And since the issues do not directly affect the codebase (even pull requests) but have to go through a core contributor’s hands, there’s a gating system built in. You can also put a notice to this effect (like the IETF Note Well or a software project’s LICENSE file) in the main project that the issue tracker is attached to. We’re doing something like this with COSE:
Basically, it’s a contract-of-adhesion kind of thing, where if you contribute you’re agreeing to IPR associated with it, without signing anything. Now if only we had consent receipts or something that could generate from this transaction...
— Justin
Oh sorry, you did address closing the repo. I think we can only execute on “Only primary editors should have write access to the repository and should be allowed to make changes directly to it” if we do that, and it will have the same effect on the issues, iirc.
Eve
This makes sense to me. I think James brought up using branches for everything just because he’s involved in insanely large projects. :-)
We didn’t actually conclude our discussion of whether to “close” the repo in order to look after IP hygiene, but it sort of relates to this topic. (Though pull requests from random non-participant strangers can always be put aside; it’s more the issue discussions that we were asking about).
Eve
The overhead associated with fully distributed development when there is a clear core team is not worth the headaches it can cause, especially since nobody that I can see would be taking the job of patch integrator to manage all the pull requests. Having an editor create a pull request and then merge it themselves into the main repository is just a waste of that editor’s time.
Only primary editors should have write access to the repository and should be allowed to make changes directly to it. Things that are WG consensus should go on “master” (or the appropriate version-tracked major branch), proposed solutions and text by the primary editors should go on branches in the main repository and brought to the group for feedback.
Non-editors (like myself) can fork the repository, branch, and create either pull requests or simply reference commits and issues from there.
— Justin
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/wg-uma
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com