Skip to content
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

Add governance category and mechanism for criteria renaming #130

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

evankanderson
Copy link
Contributor

Fixes #129

Per today's meeting, re-organize the documentation items relating to management of project contributors into a "governance" category with a "GV" prefix (as "GO" might be mistaken for a programming language).

@funnelfiasco
Copy link
Contributor

We should probably split this into two: creating the new category and updating the tooling to support replaced_by, etc. I'm not sure the replaced_by is necessary at this point since we haven't really "published" this, but in either case, these are related but separate concerns.

@eddie-knight
Copy link
Contributor

Agreed that this is a great long term value add. Let's not track renames yet, though.

@evankanderson
Copy link
Contributor Author

Do we want to keep track of the "holes" left when we rename criteria?

@funnelfiasco
Copy link
Contributor

Do we want to keep track of the "holes" left when we rename criteria?

My inclination is "no". My take is that we're currently in a pre-release with no API stability promises, so it's okay to make the sort of changes that we wouldn't later.

@evankanderson
Copy link
Contributor Author

Do we want to keep track of the "holes" left when we rename criteria?

My inclination is "no". My take is that we're currently in a pre-release with no API stability promises, so it's okay to make the sort of changes that we wouldn't later.

Do we want to plan then to renumber the existing criteria to collapse the holes that will be left by moving things around?

(Sorry to push on this, but I worry about confusing ourselves as well as other consumers with gaps in the numbering.)

@mlieberman85
Copy link

I think it's fine pre-release. I do think we want to ensure that post-release we are consistent.

@funnelfiasco
Copy link
Contributor

Do we want to plan then to renumber the existing criteria to collapse the holes that will be left by moving things around?

I was about to say that I don't have a strong preference, but then I realized I think I do. I'm in favor of renumbering, since later on the holes will only be in presentation. (E.g. there won't be an OSPS-XY-123 in the published version, but OSPS-XY-123 will exist in the yaml as a deprecated/renamed/whatever item)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add "governance" section
4 participants