-
Notifications
You must be signed in to change notification settings - Fork 65
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
Formalize JEP Front Matter #54
Comments
+1 from me, I'd be fine starting with the fields that are listed here. |
Thoughts on standalone JEP, or putting it into #29? |
I think it's in the spirit of #29, and I believe the key/vals that you've listed are semantically-similar to the ones that were added to that PR. If we can keep the key/vals to a minimal set, it should be easier to extend moving forward as well. @captainsafia do you think that choosing some key/val metadata to validate is within-scope of #29? |
Among the many issue from the above untested schema:
|
re: type, could it be "category"? re: description, could we max it at N characters (maybe even 255?) re: title, I agree |
#53 adds a website publishing pipeline (:tada:), and can turn YAML front matter into richer display, better SEO, automation, etc.
Presently, rendering can probably never fail, and values would just be ignored or hidden.
However, these kinds of metadata are extremely useful, and not just for publishing, especially if we can make some claims about them.
Proposed is a
jep-XXXX-jep-front-matter.md
that could use its own front matter to validate itself and all other current and proposed JEPs.Out of scope would be actually using this in CI, though it would be a pretty short CI action:
jsonschema
andpyyaml
(orajv
andjs-yaml
)Notional JEP
The text was updated successfully, but these errors were encountered: