Meta / Epic / Collection issues
Issue for brainstorming.
@markpundsack we both want and need something that can be used as such. Let's brainstorm here a bit
Design goals
- collect multiple issues, MRs
- track status of those (for instance, show task completion, whether there is a linked MR, whether the attached milestone is upcoming)
- easily add new issues (whether they exist or not)
Proposals
1. a special markdown syntax for defining issue lists
You could define something like
<issues>
- ref to an issue
- ref to another issue
</issues>which would be translated in a neat list / table, to which you can easily add new issues.
2. Deliverables
Proposed here: https://gitlab.com/gitlab-org/gitlab-ce/issues/19624
3. Make task lists more powerful
When making a task list, transform bare issue links to the descriptions and provide some meta data instead.
Turn this:
- [ ] #12399
- [ ] #12479 into:
- Super amazing issue 4/8 tasks completed - 8.12 (due Sept 22nd) - assigned to Job
- Literally the best issue ever DONE - 8.12 (due Sept 22nd) - assigned to Mark
Inspiration
- zenhub epics https://www.zenhub.com/product
Activity
Once we have issue boards, ZenHub's Epics looks awfully tempting... I wonder what issues look like raw, after turning them into epics there. Is it all in an external datastore, or are the relationships put into the issues themselves somehow.
I wonder if we're really going to make a significant dent in Epics until we do a complete view for them. But, (1) and (3) above are good starts. They each have limitations I can't get past though. e.g. I don't want markdown specifying all the meta information you're showing, and any defaults are guaranteed to annoy many people.
Maybe option 4 could be:
- Extend syntax similar to how "fixes #" triggers a relationship between a merge request and an issue.
- "includes #" or "part of #<parent-issue" could establish the relationship.
- Display the related issues outside of the description so it's controllable via UI. e.g. drag columns, click to add/remove columns
- Feels like deja vu, but I can't find the previous time we discussed this. I think it was related to blocking issues.
Option 5: Twist (1) using markdown table format
| <name> | <tasklist> | **<milestone>** <duedate> | assigned to <assignee> | |-------|----|----|----| | #12399 | | #12479 |Turns into:
Name Tasks Milestone Due Date assigned to assignee Super amazing issue 4/8 tasks completed 8.12 (due Sept 22nd) assigned to Job Literally the best issue ever DONE 8.12 (due Sept 22nd) assigned to Mark @markpundsack That looks great. I wonder if Milestones (and Deliverables, if that goes in) can be made to generate all their associated rows in a similar table without significant extra work.
What are Issue Boards? Is that like Gitlab Kanban integrated directly into Gitlab?
Issue boards are amazing! https://gitlab.com/gitlab-org/gitlab-ce/issues/17907
mentioned in issue #17907 (closed)
mentioned in issue #21179 (closed)
mentioned in issue #21453 (closed)
mentioned in issue #4058 (moved)
Now that we have issue boards, I wonder if a lot of our meta issues that cover release plans should be handled by new board types rather than meta issues. i.e. https://gitlab.com/gitlab-org/gitlab-ce/issues/21277 should NOT be an issue, it should be a board. We still need epic/meta issues for other things, like #21624 (moved) for example. But separating out the two types of problems might help us focus.
mentioned in issue #21660 (moved)
this is an awesome issue and takes https://gitlab.com/gitlab-org/gitlab-ce/issues/21179 much further
we need the + implementation for #20135 (moved) as well (https://gitlab.com/gitlab-org/gitlab-ce/issues/21179#note_14828987)
@dimitrieh Only for
3. Make task lists more powerful, I assume.-
3.related to https://gitlab.com/gitlab-org/gitlab-ce/issues/17942 Mentioned in issue #23027 (closed)
mentioned in issue #28601 (moved)
moved to gitlab#5525
Hey!
GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current
gitlab-cerepository will become a read-only mirror, without any proprietary code. All development is moved to the currentgitlab-eerepository, which we will rename to justgitlabin the coming weeks. As part of this migration, issues will be moved to the currentgitlab-eeproject.If you have any questions about all of this, please ask them in our dedicated FAQ issue.
https://gitlab.com/gitlab-org/gitlab-ee/issues/13855You can also find more information here:
https://gitlab.com/gitlab-org/gitlab-ee/issues/13304- https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/
Frequently Asked Questions
For an up to date list of questions and answers, please take a look at
https://gitlab.com/gitlab-org/gitlab-ee/issues/13855What will we do with the repository names?
https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.
Why rename gitlab-ce to gitlab-foss?
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear
I created a merge requests for CE, and this got closed. What do I need to do?
You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.
How does the licensing work in this new setup?
Everything in the
ee/directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in theee/directory, the process of contributing changes is the same as when using the gitlab-ce repository.Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?
https://gitlab.com/gitlab-org/gitlab-ee/issues/13304Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?
Yes, these changes will be synced to gitlab-foss automatically, several times per day.
