Open ContiMary opened 1 year ago
@ContiMary the current fork (as of 08:38 JST 6th September) is just intended to provide a template. We need to chop out the middle (after 3.1.1) and re-populate it with (a) material from the open issues and (b) notes like above :)
The first action item I will take will be to do that chop so readers are not confused, and we can repopulate from a more blank slate.
The draft has now been updated to chop out material, make placeholders and make status clearer: https://github.com/OpenChain-Project/Contribution-Process-Specification/blob/main/1.0/en/1.0.md
Focus on this issue will now turn to: "For Contribution, I see 2 main use cases: 1) The company provides some Open Source in a way (github or other) that others can use in an open source manner and 2) developers contributing back bug fixes or features to public repos that their company does not own." + "I also miss any reference to how the different open source communities work. Of course, this document should not get into these details, but maybe suggesting that potential contributors must familiarize themselves with the community they want to contribute to, and that community's practices."
Does that address your concerns?
I think the discussion in #7 is relevant here as well. can we merge the two?
I was surprised by this document because it sounds mostly like the Open Chain spec, and not adequately differentiated for Contribution. For Contribution, I see 2 main use cases: 1) The company provides some Open Source in a way (github or other) that others can use in an open source manner and 2) developers contributing back bug fixes or features to public repos that their company does not own.
I don't even see these use cases mentioned and don't see any clear distinction between them or how they should be handled. It actually sounds like license compliance should be run on every single commit no matter the size or scope, and that's going to get nutty and will basically stop any contribution by employees.
I also miss any reference to how the different open source communities work. Of course, this document should not get into these details, but maybe suggesting that potential contributors must familiarize themselves with the community they want to contribute to, and that community's practices.