This repository has been archived by the owner on Dec 21, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 528
Improve the structure of the docs #474
Labels
good first issue
Good for newcomers
hacktoberfest-accepted
🙏 help wanted
Help wanted - not prioritized by core team
Comments
A few examples to compare against: |
Hacktoberfest update: |
@mlvandijk @mpkorstanje is this available to pick up? I'd be happy to work on it. |
Absolutely! We'd love your help. |
@mlvandijk I can remove the teams page & the introduction page. |
@pattimcletchie Sure, go ahead! Let me know if you need any help. :) |
Merged
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
good first issue
Good for newcomers
hacktoberfest-accepted
🙏 help wanted
Help wanted - not prioritized by core team
Currently the structure of the cucumber docs is rather confused. Content with different goals is grouped together. This makes for a poor first user experience and a rather confused second user experience. This can be improved by changing the structure and rewriting the articles to conform to one of the types of docs below:
Types of docs
Like the Getting Started document I mentioned previously, this is the place where you tell users what they need to know before they even get started.
The reference guide is comprehensive and usually pretty dry. This is where terms are defined, functions' input and output are explained, and examples are given. The tone is factual and to the point. There's not much discussion, or conversation. The voice is usually impersonal.
Tutorials hold your hand and lead you down the path. They show you each step, and occasionally sit down on a bench by the path to explain the rationale for a particular step. They are very conversational, sometimes even chatty. The voice is personal; you are speaking to a particular person, defined in the earlier persona phase.
Often linked to from the tutorials, the learning/understanding documents dig deeper. They investigate the why and the how of a particular thing. Why was a certain decision made? How was it implemented in the code? What does the future look like for this thing? How can you help create that future? These documents are sometimes better done as blog posts than as part of the formal documentation, as they can be a serious distraction to people that are just trying to solve a problem.
Structure
With this in mind the structure should be
Fix some issues:
@mlvandijk @gasparnagy @danascheider
The text was updated successfully, but these errors were encountered: