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

Minor ideas #9

Open
phseiff opened this issue Mar 17, 2021 · 0 comments
Open

Minor ideas #9

phseiff opened this issue Mar 17, 2021 · 0 comments

Comments

@phseiff
Copy link
Owner

phseiff commented Mar 17, 2021

I use this issue to dump small ideas for this project whom I would like to realize sooner or later, or see realized.
All of them are minor things, just ideas that I'd like to share here for transparency and to give people a chance to object or offer themselves to implement them, and to help me organize them better.

  • An RSS feed to inform people of specification releases. This might sound like a minor improvement, but it might help to get more feedback on specification changes in the long run, since many people might have an interest in the project without having a GitHub account, due to the relatively IT-unrelated vision of the project (compared to other IT projects, at least).
  • An "additional reading"-section in the README, that links to relevant resources and issues
  • An in-depth guide to gender*render that extends the quick-start guide and works without having to read the specification, or at least a link to the specification at the end of the quick-start guide.
  • Modification on the spec download section:
    • The title of the spec next to every specification name
    • Hiding older versions in a dropdown that can be clicked on to show them (relevant once there are more versions)
    • The version of the latest version and a link to its html version next to the "download latest"-link
  • A maintenance document (linked in the additional reading section) in which I outline how I maintain the repository, how releases are made and handled, how I version stuff, how I use git, how I develop the specification and its features, how I use issues for organization et cetera, so people can continue this project as a fork in case something happens to me (this is a measurement recommended to all open source projects), and to increase transparency
  • A section in the README on how one can support the project, that asks for feedback and explains how giving stars is valuable since it helps the project get to trending, therefore increasing the odds of people seeing it there and potentially becoming more aware of the issues the project tackles (or maybe link that in the additional reading section?)
  • Evaluate in how far adding things into these handy hide-until-someone-clicks-it-tags that GitHub offers in the README might help with organizing it and making things easier to access that wouldn't have fit into the README otherwise
  • Create (and link to the additional reading section) a document that broadly explains the project to non-tech people, so I (and other people) can share the link to said document with non-tech people who might be interested in the project or take inspiration from the explanations there (this is relevant since the project's mission is not only relevant to tech people)
  • I would like to keep all of these things in the repository itself rather than a wiki to have them version controlled and integrated into every clone of the repo.
  • Improve the banner of the repository (the one that is embedded into every link to the project) to show the whole name and a tiny explanation of what it is and does.
  • Maybe add a better starting section to the README, that explains the issue the project tackles from a "look how gender selection forms usually work"-perspective rather than a "look at it from the server side!"-perspective, to be more intuitive and start at a point that's more familiar to most people?
  • Should I make the examples in the quickstart section less specific? People could think that only a limited set of pronouns and id-values is supported if I use specific ones in my examples rather than generic values like "foo" and "bar". On the other hand, having specific values for a specific example makes it easier to grasp why features are important.
  • I should probably add more subsub-sections and subsubsub-sections to the specification, plus include a deeper nestling depth into the table of contents, to make it easier to read and navigate.
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

1 participant