Reformat issue boards docs
- Separate "Actions you can take on an issue board" and nest under Issue Boards
- "Advanced" features - yucky
- How it works - tighten up and integrate into the intro section - turn into concept topic
- Talk about using IBs first, and then give examples/usecases
- "Use cases" -> "Issue Boards use cases/examples"
Advanced team handover - needs intro and more context
- Rename: "Using issue boards with multiple teams" or "Issue board workflow between teams"
- Incorporate "enterprise features" into the intro, or at least the tier comparison table
- s/Configurable/Configure Issue Boards
- "Issue ordering" -> "How GitLab orders issues in a list"
"ing" words often indicate that there is no subject and it's good to try to revise.
their assigned labels. Issues are represented as cards throughout those lists.
If you look a little closer, it's not even clear what this sentence is saying, I think. Does it mean something like this?
With GitLab Issue Boards, your issues are displayed as cards. These cards are in columns, based on each issue's label.
"pull in" is not clear. (Does it mean drag from somewhere?)
"from one step to the next" - What does this really mean?
I would try to re-write the whole intro with simplified language. (I don't expect you to do that, I'm just saying what I notice.)
This title is a red flag to me. Have you ever done a google search for the phrase "Advanced features"? Probably not.
This is an indication to be more specific. If what follows is a random list, try to find better homes for the information, under titles that are more specific.
Someone might search for "How to create multiple issue boards per project," for example.
Is this meant to be "How to create an Issue Board"? (Better for search results if you can change)
OK this is getting closer to explaining what an Issue Board is, but there is one place for this conceptual info: In the introduction.
There are three main types of content in the world:
- Concept (teach me what something is)
- Task (give me steps to do it)
- Reference (tell me what this widget in the UI does; only needed when the UI is not self-explanatory)
Based on the title "How to create an issue board" I would expect this to be a task with steps.
Less is more. You can probably cut down a lot of this detail...
This is all conceptual, and a lot of it is marketing. If I'm in the product help, I have usually already purchased the product and I don't need to be sold. Just tell me 1) what this thing is and 2) how to use it.
If I need to be sold I may look at the product docs, but it's because I want to know I'll be able to find help if I buy this thing.
I've also never google searched for "use case."
I would want to know "How to use an Issue Board" and you can write an intro sentence that says this is a basic, common workflow.
Then the next task is "How to use multiple Issue Boards."
I would get rid of the use case language. We should not tell them the use cases GitLab thought of when developing, we want them to know we're thinking of them, and how they will use it.
Sometimes Frontend is capitalized and bold, sometimes it isn't.
Try to be consistent with usage. The Front-end team?
Not sure of meaning of the title?
I thought this was covered above? Can you combine all of the information about Multiple Issue boards into one area?
This would be nice if it was Configure an Issue Board by Label, Assignee, and Weight? And if it were a task?
Be active when possible. Order issues in a list?