-
Notifications
You must be signed in to change notification settings - Fork 634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update the contributor-strategy.md information page for enduring validity. #1126
base: main
Are you sure you want to change the base?
Update the contributor-strategy.md information page for enduring validity. #1126
Conversation
Signed-off-by: Riaan Kleinhans <[email protected]>
+1 on this! When I check the charter documents of other TAGs in this repository, I see they all have content and not just links to the charter documents in their own repository. Ex: network, app-delivery IMO, it would be much better to have a single charter document. ...and, ideally all TAG charter docs in this repository should also go with the same approach. |
Co-authored-by: Ali Ok <[email protected]> Signed-off-by: Riaan Kleinhans <[email protected]>
Co-authored-by: Ali Ok <[email protected]> Signed-off-by: Riaan Kleinhans <[email protected]>
Co-authored-by: Ali Ok <[email protected]> Signed-off-by: Riaan Kleinhans <[email protected]>
This raises a general question for the TOC. Currently, most TAGs have duplicate (and inconsistent) information in the toc/tags folder, and in their individual repo READMEs. Where should canonical TAG information live? It needs to be one or the other, because clearly maintaining the same text in both places doesn't work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am generally in support of this so long as each TAG has governance in place to ensure any changes to their Charter received concurrence from the TOC prior to merge.
@jeefy given Amye is out, do you know if there is any reason TAG Charters need to exist within the TOC repo if we have processes in place to ensure updates are approved by the TOC?
This was sort of organically grown. We wanted one place to track all of the charters when they were approved, but given as the charters have shifted, that may not be as relevant anymore. |
We did some backlog grooming and I took this one -I've had a chance to review and this isn't quite the right place for this. @Riaankl - does that make sense? |
Signed-off-by: Riaan Kleinhans <[email protected]>
@amye yes, renaming it as "About CNCF TAG Contributor Strategy" is a good idea. Our roadmapping and clean-up that we are working on in the TAG CS repo leaked out into this document. TIA |
Ok, so yes - but we're still overwriting the charter. Let's do this: |
The charter live in the TAG CS repo.They got badly out of sync because there are two copies. My thought about this was under "TOC/TAG" directory we only have a intro to each TAG that would not get dated, and a link to their repo that include their charter. (Kind of a restructuring proposal for all, but leading by example) |
@riaankleinhans can you confirm if this PR is up to date with the recent recommendations and changes regarding the TAGs? If so, could you update the PR to resolve the existing conflicts? |
No, this need to be updated. |
@riaankleinhans is there a status on this PR? Has TAG CS updated their charter? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
even with the charter out of date, it is outside the scope of this PR as i understand it. @riaankleinhans @mrbobbytables could you confirm so we can get this merged? |
The update aims to provide stable, timeless information that avoids references to individuals, working groups, and objectives subject to change, reducing maintenance efforts while ensuring up-to-date content.
Fix issue: cncf/tag-contributor-strategy#464