WIP: feat: C4 working to draft #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "TyIsI/coreprotocol-rfcs:feat/C4-final-updates"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This pull request is to update the raw C4 proposal to draft status and update it with various elements to modernize it and reflect the times.
This Collective Code Construction Contract provides governance for all CoreProtocol projects and contracts.
Feedback and comments are welcome on this PR.
@enot thoughts so far?
I have thoughts lol
Happy to go whatever route, I just have preferences in flow for the reasons described.
@ -27,104 +29,111 @@ C4 provides a standard process for contributing, evaluating and discussing improThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119).A capitalized word in quotes shall thereafter be used as a "Term". That Term maybe subsequently appear without quotes.s/That term maybe/That term may
@ -51,0 +52,4 @@1. The Project SHALL use the Platform issue tracker.1. The Project SHOULD have clearly documented guidelines for code style.1. A "Change" can consist of a solution to a problem, issue, feature and/or any other change.1. A "Commit" is a clear identified derivative Change to the software or configuration contained in the Project.I think these are the other way around. For example you could create a commit in interactive patch mode and select single changes to include in the commit. So a patch is a clear identified derivative change and a commit is a collection of one or more patches.
Edit: Maybe given the later language around submitting patches, and because patch and commit can describe the same types of changes with the difference being that a patch is the change and a commit is the application of that change to the codebase: We should just reword the Commit section to be clear that a commit is the committal of applying the changes to the source. But perhaps worded better.
@ -51,0 +56,4 @@- https://en.wikipedia.org/wiki/Patch_(computing)#Source_code_patching1. A Patch is a bundle of Commits that implements a clearly identified Change.1. A "Contributor" is a person who wishes to provide a Patch.1. A "Maintainer" is a person who merges Patches to the Project. Maintainers are not developers; their job is to enforce process.I'm not sure how I feel about this. I don't think that a maintainer cannot also be a developer and I'm not sure we want non developers deciding if things get merged. Bu I suppose that is cleared up further down where a contributor can also be a maintainer.
@ -51,1 +59,4 @@1. A "Maintainer" is a person who merges Patches to the Project. Maintainers are not developers; their job is to enforce process.1. A "Patch Request" is an integrated technical means on the Platform to submit a Patch for review by the Maintainers.- E.g. a pull request or a merge request.1. Contributors SHALL NOT have commit access to the repository unless they are also Maintainers.See next; wherein contributors would have push access to anything except main.
@ -92,2 +93,2 @@1. Any Contributor who has value judgments on a patch SHOULD express these via their own patches.1. Maintainers SHOULD close user issues that are left open without action for an uncomfortable period of time.1. Thus, the release history of the Project SHALL be a list of meaningful logged and solved Changes.1. To work on an issue, a Contributor SHALL fork the Project repository and then work on their forked repository.This I much prefer to share a repository that only maintainers have push access to main, otherwise contributors have push access to any other branch and we don't have to fork. The whole flow of Git is based on branches and patches so there is no need to follow github et al and use forking to contribute. And honestly as someone who has been the green new developer, getting included in the project in this was is a huge boost to confidence and a feeling of being part of the team. It does require more effort to manage permissions up front but afterward works very well. A fork was always meant to be a divergence from the source, to go in another direction entirely.
@ -97,2 +110,2 @@1. The project SHALL have one branch ("main") that always holds the latest in-progress version and SHOULD always build.1. The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.1. The Project SHALL have one branch ("main") that always holds the latest in-progress version and SHOULD always build.1. The Project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.What is the issue with topic branches? Like if a few contributors wanted to collaborate on some change they should be able to do so.
When you look at it from an RBAC perspective, it takes more work to filter access for specific contributors on a specific topic branch.
I.e. when you add them as collaborators, they get blanket access to all not-protected branches and tags.
So if a Maintainer were to invite patches or merges on a collaborative branch, that would not be a problem, or individuals could work together, but if it needs to go through the merge process anyway, then why would it need to be in the main repo in the first place?
Also, the change here was mostly formatting (removing the list).
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.