-
Notifications
You must be signed in to change notification settings - Fork 674
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
V2 Release #3489
Comments
These issues are fine for general talk, but right now the rest of it is backward. Milestones are for milestones and projects are broader, and can use milestones in organization and display of items in the project. For example, just one project for V2, and then milestones for Alpha, Beta, Release, and any others that may come up along the way. Milestones are almost glorified tags, but they have first-class application on the repo main page as well as for organization of items in projects. Milestones also often get used for when there's specific new feature work. Basically, every organization should have projects, and fewer open projects than the number of repositories they have, since Projects are also a cross-repository entity and thus can have issues in them from one or more repositories in the org And then every repository should have milestones for times when there will be multiple issues directly relevant to that same body of work. Milestones are repo-local. |
Then you can optionally add Milestone as a group-by item in Project views. |
To relate that terminology to Jira, if you've ever used that, Milestones are "Epics" Projects are Jira "Workflows." |
Yep. Thanks for pointing this out.
Done. LMK if you have more feedback on this. |
I like how that's shaping up. :) My only particular comment as far as the project goes is that it would be good to have at least these two:
The analogy I gave to relate it to Jira is not perfect, because Jira doesn't really have the specific kind of separation of the concepts of a repo and project that github does (which sorta makes sense, since Jira isn't, itself, a source control system). Typically, on GitHub, you'll have the organization (gui-cs in our case). Organizations have repositories. At the basic level, they're merely git repositories. But GitHub provides a lot more, as a full project management platform. Issues belong to repositories and cannot exist outside of one. Projects are long-term collections of work related to a common goal. So, for us, the projects above are probably a good basic layout. Milestones belong to repositories. Issues can link to a milestone defined for the repository the issue belongs to. The milestones you made look pretty good to me, at the moment. If and when we have large development efforts that span more than one issue, that's when we'd throw up a new milestone. Once all work for a milestone is completed, the milestone is also closed. Issues themselves belong to repositories. They can link to one or more projects, and can link to one milestone. They can have different statuses in every project they link to, so they can be appropriately classified for the purposes of each project. So, to summarize a standard layout of things, we would have these projects: Currently (3 projects)
After V2 is released (4 projects)
Of course more are fine. As for milestones, post-release, those would generally be for features associated with the next minor version, and there may very well be times when there aren't any around, if we don't have anything formally taped out yet. |
As for the current state of the project currently defined, I did add an additional status that helps differentiate between issues that are closed because they were work that has been completed vs issues that are closed for other reasons like cancellation, abandonment, change of direction, obsolescence, etc. Some projects split that out more granularly, but I don't really think we need to bother with that. It's easier just to have an optional field for the reason, if you wanted to track that specifically. In any case, it's looking a LOT better and the suggestions in the above comment are actually pretty painless since you can just copy the project to create any of the new ones and then tweak the copy as necessary. |
Also note that github actions/workflows can be set up to automate stuff to your heart's content. You can have it auto-assign newly-posted issues to a specific project (that can also be done in issue templates), trigger automatic branch creation on assignment to specific projects, update status badges, and all sorts of goodies, should anyone want to bother with any of that. |
Oh and of course feel free to modify the name/description/etc of the new status label I added to the project. I tried to follow your nice little scheme of emoji + name. (I'm probably going to adopt that for internal projects at work, too. Nice.) Another common name for that label is "Declined" and it was basically a coin toss for me between that and what it is currently. |
I also usually include status labels like one for Paused/Hold/etc, which is used on issues that have been worked on but are on hold for some reason, so there's a much better picture of where active development work actually is happening. Most of the internal projects at work have that and an optional field with the reason for or nature of the hold (like blocked, developer priorities, etc), which is sometimes handy for example when triaging work items. I also often like to have optional fields for specifying the PR/Issue number (issues put PR number and PRs put issue number). That's a cleaner and github API queryable way of associating things, especially for something like this repo, where most contributors will not be an org member with write access to the repo and thus can't link their dev branch to the issue. |
I took your input above and mostly did it. |
Coolio. Haven't looked at anything today, as I had guests for a Memorial Day weekend get-together, but I'll certainly have a look tomorrow. I'm sure it's probably great. :) |
This is the master Issue for the "Final" Terminal.Gui v2 Release.
When we do the final merge to v2 from v2_develop to Release v2, that PR will be titled "Fixes #3489. Launch Terminal.Gui v2".
The text was updated successfully, but these errors were encountered: