-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
A proposal for guideline pages #752
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
> [!TIP] | ||
> The guidelines are not formal design patterns, rather they are helpful principles and concepts that are not always well defined. With that in mind, feel free to take liberties with the suggested format. Furthermore, not every guideline requires further explanation. | ||
|
||
## Guidelines |
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 we accept these meta-guidelines, we should use a linter of sorts to enforce them (at least the ones we can)
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.
That would be a useful tool to have 👍
I could see the headings being an easy one to enforce.
- Prefer repeating patterns found in other guides, but there's no conventions set here yet. | ||
- A **reference** section includes links to resources and pull-requests | ||
|
||
## Page Template |
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.
Once we have one, a real example would be good
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.
here's a WIP example - main...vb-modifying-nme-standard
@@ -0,0 +1,100 @@ | |||
# Guide To Writing Guideline Pages | |||
|
|||
## What are guideline pages? |
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.
Should all guidelines have a page?
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.
🤔 That's a great question...
- initially I think it'd be unreasonable to enforce this for all existing guidelines. I wouldn't want to rapidly generate a bunch of pages. If we went that direction, I think it should be thoughtful and deliberate.
- I do think that there are a lot of existing guidelines that could benefit from a revisit and adding a guideline page to flesh out our thoughts on why it's useful and important to follow.
- Having reasoning behind every guideline, even ones that appear obvious, can make them more approachable to everyone and to every level of experience. The work that goes into articulating the reasoning behind a guideline can facilitate analysis of assumptions; avoid miscommunication or confusion; clarify one's thinking; and reveal gaps in our own understanding.
- I could see enforcing this for new guidelines. It can encourage discussion and preserve more context for the next time someone reviews a guideline to see if it's still as relevant and applicable as it once was.
```markdown | ||
# Use a prepositional pharse in sentence case for titles | ||
|
||
## Guideline |
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.
At first glance, this seems too rigid to apply to all pages. I'd love for us to experiment with just having guideline pages at all before defining such a strict format. That said, it might be good to have some form of template to help shape ideas/thoughts.
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've imagined this being more of a starting point to underscore the angles from which we might examine a guideline and to identify the components which could be put into an articulated reasoning. This is more to encourage a bit of internal consistency of approach. The emphasis is not on following a specific structure.
- There's virtue to irregularity. I'd like to encourage common components, but highly encourage creativity and flexibility in how that is composed and presented.
- at the same time, repetition is a valuable cue
- So an effective strategy is the artful combination of irregularity with some order to signal intent. Building more of a garden that composes structural elements with surprise and experimentation. Avoiding the sterility and rigidity of farmland while also avoiding untamed wilderness.
Also things that are entirely unsurprising yield no information (surprisal being a measure for the amount of information exchanged in a communication between two entities).
So yes, I would love to explore more formats
A proposal for structuring sub-pages that provide additional details to guidelines.
Example:
README.md
file:guides/ruby/README.md
Line 5 in d7bd2d1
guides/ruby/Use an opinionated set of rules for Rubocop.md
Line 1 in d7bd2d1