-
-
Notifications
You must be signed in to change notification settings - Fork 530
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
Improve the structure of the docs #474
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. :) |
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: