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

Give each unique principle its own page #31

Open
evanwolf opened this issue Dec 11, 2017 · 1 comment
Open

Give each unique principle its own page #31

evanwolf opened this issue Dec 11, 2017 · 1 comment

Comments

@evanwolf
Copy link

Would be great to have a canonical place for each principle. Makes it easy cite in writing an Our Principles list or in conversational media. And to resolve similar-but-not-the-same principles.

The principle profile would list Examples where it was used, a gist describing the principle, and pointers on where to learn more. Each Example would link to the individual principle pages.

It's one thing to read five or even twenty lists. But few people will read more than 100. But one page where you can read everyone's principles in one long list? Scannable. We could even cluster related principles together.

@benbrignell
Copy link
Owner

This ties in closely with issue #3. I sort of see this as part of tagging. For ubiquitous principles the idea of browsing principles-first would work well this way.

However the limitations of github pages/jekyll plugins make this a bit of a headache. It's not impossible but the only way I'm aware of to do this requires a layout for each tag/principle to be made. Doing so would be a fair deal of manual effort to maintain as more examples are added.

When tags are implemented I see them being a finite list of things. Maybe we could identify a finite list of ubiquitous principles and surface them differently to tags.

Tags in general would be set as something like personal, user experience, specific etc and we could incorporate 'tags' for types of principles such as consistent, fast, trustworthy.

My concerns would be that:

  • They end up being too vague/generic and not much value
  • It's another significant overhead for contributors to tag things up this way

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

No branches or pull requests

2 participants