-
-
Notifications
You must be signed in to change notification settings - Fork 11
Add contributing guidelines #112
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
base: main
Are you sure you want to change the base?
Conversation
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.
My personal view is that this document should be used as a way to quickly find precedents, but that new names should always be motivated by existing symbols. In other words, those guidelines should reflect the existing conventions and shouldn't be used as a source of truth--the only source of truth is the existing names. For this reason, I strongly believe every rule in this document should be supported by one or multiple examples. This is reflected in my proposed rephrasing of the first paragraph.
Unrelatedly, if this document aims to be contributor guidelines, it might benefit from some of the links from the "Useful links" section of the proposals document. Maybe even a link to the document itself.
Co-authored-by: Malo <[email protected]>
Co-authored-by: Malo <[email protected]>
Another question that should be resolved: Should Or, going further, perhaps the whole distinction should be removed entirely? (Tho I personally like it.) |
Changing the title to reflect the broader scope. |
Co-authored-by: Malo <[email protected]>
Also, I forgot to say this earlier: Thanks for the thorough review! |
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.
Or, going further, perhaps the whole distinction should be removed entirely?
Maybe just ordering the modifiers from most concrete to least concrete would be enough. I personally don't see a clear cut distinction.
CONTRIBUTING.md
Outdated
- `.l`/`.r`/`.t`/`.b`: The four main directions (left/right/top/bottom). | ||
- For delimiters, `.l` means opening and `.r` means closing (see [#100](https://github.com/typst/codex/pull/100)). | ||
- `.tl`/`.tr`/`.bl`/`.br`: The four corners | ||
<!-- TODO: Do we have or want to have conventions about when to choose `.tl` vs. `.t.l`? --> |
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.
If you mean a clarification regarding corner delimiters, I don't think this is necessary.
Hmmm, I'd like to hear the other maintainers' opinions on this. Tho I'd definitely want to order them from least to most concrete instead. |
I think it would be helpful to have them organized alphabetically, at least within a category. |
Co-authored-by: Malo <[email protected]>
I've now decided on "yes". |
I kept some groups in the generic section that are still sort of ordered by importance, but the others are now sorted alphabetically. |
Co-authored-by: Malo <[email protected]>
I'm wrong |
As mentioned in #110 (comment).
These conventions are clearly contributing guidelines, so I went with
CONTRIBUTING.md
for the file name. That way we can also add other contributing guidelines in the future, if we want to.If you want to reword something or add other conventions that I may have missed, don't hesitate to leave a comment.
From my side, there's only one unresolved question left here (which I also left as a TODO comment in the file itself), namely whether we want to write something about when we choose e.g.
.t.r
over.tr
for corners (cf. #100).