-
Notifications
You must be signed in to change notification settings - Fork 126
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
Issue state tracking using GitHub labels #2896
Comments
Hi I am Prasanth. I've thoroughly reviewed the proposal you've outlined for improving our GitHub issue management system, and I'm impressed with the clarity and thoughtfulness of your suggestions. It's clear that implementing a label-based lifecycle will greatly enhance visibility and efficiency for both contributors and maintainers. I'm eager to take ownership of this initiative and ensure its successful implementation within our project. With my experience and a commitment to streamlining our processes, I'm confident in my ability to lead this effort effectively. I propose to begin by creating and applying the necessary labels, updating relevant documentation, and potentially automating certain tasks through GitHub Actions. I'm open to collaboration and feedback from the community. Please let me know your thoughts on proceeding with this plan. Thanks. |
hi! thanks for your interest, but this will maybe be part of the GSoC project so we can't assign it somebody else currently. |
I'm planning to participate in GSoC this year and believe tackling this issue is key to preparing for it. As setting up issue labels is a crucial first step for the GitHub issue self-assignment bot, I'd like to focus on it initially. |
the status labels were created |
Goal
As a Keptn community member, I want to see at a glance, what the state of a GitHub issue is.
Details
It seems that this project has some problems with issues not being clear on the state they are in. Right now, we track the state of an issue through GitHub projects [1]. This could be improved by using labels instead. A big advantage for that is that users will see the labels directly in the list of issues as compared to only in the GitHub project that is not used by contributors or the community mostly (it's used by the core maintainer team mostly I think).
I suggest the following state lifecycle:
status: needs-triage
: added automatically on newly created issuesstatus: draft
: issue is in drafting/shaping stage. The issue will be refined soo when this stage is donestatus: ready-for-refinement
: issue is fully written up and is ready to be refined in one of the next community meetingsstatus: todo
: the issue is ready to be picked up by a person to be worked uponstatus: assigned
: the issue was assigned but no PR was created yetstatus: in-progress
: the issue is being worked on, a PR was created in draft modestatus: in-review
: the issue has an open PR that is not in draft modestatus: done
: the issue is done and the PR is mergedstatus: wont-fix
: a closed issue that will not be worked on, can't be reproduced etc.status: needs-discussion
: (not part of the lifecycle) used for issues that should be discussed in a community meeting but that are maybe not yet ready to be refined and need preliminary discussionNotes
This issue would also help with automating the issue assignment process as discussed in #2823.
[1]:
The text was updated successfully, but these errors were encountered: