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

Move spec org/group/status info to a config file #2908

Merged
merged 25 commits into from
Aug 26, 2024
Merged

Move spec org/group/status info to a config file #2908

merged 25 commits into from
Aug 26, 2024

Conversation

tabatkins
Copy link
Collaborator

Currently, info about what Groups and Statuses exist, and which groups are part of what org, etc. are all tracked in some Python data structures in config/status.py, meaning I have to roll a new version of Bikeshed whenever someone adds a new Group to the boilerplate repo and wants it to be recognized as a W3C group or something.

This change moves those data structures into a config file, boilerplate/doctypes.kdl, which now lives in the bikeshed-boilerplate project. It also significantly restructures how I deal with the information previously in that Python file.

  • I reify the concept of an "org", previously a special case just for the W3C and implied in the "canonicalized" form of the status shortnames. An org contains 1 or more groups and 1 or more statuses, and namespaces both of them. You can set your org via the new Org metadata, or imply it by using a Group or Status with it as a prefix, like w3c/wd (implying Org:w3c and Status:wd)
  • Org, Group, and Status are now data structures, not just strings, and live on the Spec object collected in a Doctype object, rather than in the metadata. (The metadata still contains the strings that were passed, of course.) This allows for easier normalization and regularization of access, fixing some bugs I didn't realize I was experiencing (wrt casing of values, and "canonicalized" vs un-.)
  • Previously I allowed unknown Groups; I now emit an error in that case. I think it's more useful to know if you're using a known Group value or accidentally have a typo or something. It's very easy to add new Groups now, and if you don't have Group-specific boilerplate you don't even need to say anything; just the Status and possibly the Org is enough.

…s PR's actual changes were tested on these files earlier.
@tabatkins tabatkins merged commit 5e18317 into main Aug 26, 2024
18 of 19 checks passed
@tabatkins tabatkins deleted the kdl-status branch August 26, 2024 22:45
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.

1 participant