Collective Code Construction Contract - C4.1
pdamoc opened this issue · comments
I propose that the elm-community adopt a clear and explicit contract for all projects hosted here.
I propose that this contract be modeled after the ZeroMQ RFC 22:
Collective Code Construction Contract - C4.1
I propose that the forks be relicensed under MPLv2 if the original was MIT.
I propose we add a section that explicitly states that the Native projects hosted here MUST be kept up-to-date with the latest developments in Elm internal architecture. This common commitment could be good grounds for a whitelist of all elm-community projects on package.elm-lang.org.
Can you comment on the differences between the MPLv2 and the MIT licences? What problems would relicensing solve, in your view?
The ZeroMQ C4.1 looks generally attractive to me, but I wonder what else is out there -- someone initially raised the ZeroMQ model, so we've sort of focused on that, but I wonder whether there are other models we should consider? Not that we necessarily need an exhaustive search, of course!
As far as a "blanket" native whitelisting for elm-community stuff goes, I guess it would be convenient. However, I think that Evan sees multiple reasons for blocking native modules at this time -- that is, I don't think it necessarily helps to focus too much on any one reason for the block, because it's really a constellation of issues, and we're unlikely to be able to address them all. But, I'd be happy to be wrong about that!
I've read Pieter Hintjens argumentation here and it made sense to me. I think MPLv2 might encourage more contribution.
I too wonder what else is there in terms of community architecture. Maybe some else can provide an alternative.
Regarding Native whitelisting, maybe I should be more forthcoming and admit that I am not familiar with the internals of Elm. It just sounded like a good idea as a way to unblock the process. Maybe Evan or someone with more knowledge of the possible disadvantages of this approach could provide their input. If it turns out that it is an unmanageable constellation of issues, then so be it. My hope is that it might be just a case of a need for a higher than usual code quality (which can be codified in a process that a regular user might not want to go through but the maintainers of elm-community might be willing to go through).
As far as the licence goes, I think we should keep it in mind but not necessarily be too rigid about it. I say that for two reasons:
- Nothing we're hosting here (yet) is so intrinsically complex as to require too much worry about forks -- that is, it's nice to be able to cooperate on this stuff, but none of it is so complex (yet) that we'd be sorry to lose control of it. But, I suppose there could be something like that eventually.
- If we do re-licence things under a more restrictive licence than the original author, then we're actually (potentially) the bad guys in the story you linked to, not the good guys. That is, we'd be the one doing additional work that the original author would now not be able to use under the original author's licence. Or, at least potentially so.
On the C4.1, what I would propose to do is start by operating in its spirit -- which, I think, is generally an attractive one for our mandate -- without necessarily focusing too hard on its exact provisions.
One thing which I'd like to try out for myself is the "don't merge your own PR's" philosophy -- that was one thing in the C4.1 which I found a little counter-intuitive at first. But the more I thought about it, the more it seemed like it might have some interesting effects. (Essentially, it does give a second set of eyes on things, and it means that at least one other person has taken some interest in the code).
The other process we might want to work out is a process for actually releasing new package versions to the Elm package repository. At least at first, I would suggest that when it makes sense to do that, someone create an issue proposing to do so, and wait a day or two before actually doing it. That way, if there is anything to think about in terms of what features ought to go with other features etc., it could be discussed. Also, if we're a little cautious about a second-look before releasing something, then we can feel a little more liberal about accepting pull requests.
Closing as stale (>1 year old).