chore: create issue templates for project planning #361
Conversation
|
Here is a quick preview of how this would look in the
|
related: kubeflow#327 This commit creates 3 new GitHub issue templates to help with Notebooks 2.0 project planning. As recently agreed upon in community meetings - we want to break down work into 3 hierarchical categories: - Epics - Features - Tasks The templates defined in this pull request mimic the format @ederign used when initially defining work for our first "sprint" of work. :warning: Please note, however, I have introduced the term `Task` to capture the most granular issue type. Happy to change the word to something else - but wanted a `[...]` prefix to identify these issues similar to `[EPIC]` and `[FEATURE]` These issue templates would not be intended to be used by "random" community members - rather they are designed to aid Epic Owners in defining work. For now, I have just added a simple "disclaimer" in the issue template summary to discourage use. In the future we could discuss extending `internal-acls` and leveraging GitHub Actions to ensure these "planning" templates are only used by designated community members. Additionally, the `Epic` and `Feature` templates presently have a section to track child items included in the issue description. This accurately captures our process today but the desire in the future is to implement kubeflow#325 to leverage GitHub sub-issues to more naturally track these relationships (at which point we'd remove these sections from the template). Signed-off-by: Andy Stoneberg <[email protected]>
andyatmiami
force-pushed
the
chore/project-planning-templates
branch
from
0c97ea4 to
a24bfa9
Compare
| @@ -0,0 +1,16 @@ | |||
| --- | |||
| name: 🔧 Task (Planning) | |||
| about: 🛑 Only intended to be used by Kubeflow Notebooks 2.0 project managers | |||
There was a problem hiding this comment.
Andy, a task can be created also by the project members isn't?
There was a problem hiding this comment.
I was viewing this use case (GH issue created by non-project member) to just be a "normal" issue opened in the repo
so a blank issue or enhancement request or whatever - but NOT this template
a project member could then always choose to add it to a feature/epic.. but i was really trying in my vision here to very clearly delineate the "planned work outlined from Epic owners" vs. "anything else that might have been created"
|
/approve |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ederign The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/ok-to-test |
related: #327
This commit creates 3 new GitHub issue templates to help with Notebooks 2.0 project planning.
As recently agreed upon in community meetings - we want to break down work into 3 hierarchical categories:
The templates defined in this pull request mimic the format @ederign used when initially defining work for our first "sprint" of work.
Taskto capture the most granular issue type. Happy to change the word to something else - but wanted a[...]prefix to identify these issues similar to[EPIC]and[FEATURE]These issue templates would not be intended to be used by "random" community members - rather they are designed to aid Epic Owners in defining work. For now, I have just added a simple "disclaimer" in the issue template summary to discourage use. In the future we could discuss extending
internal-aclsand leveraging GitHub Actions to ensure these "planning" templates are only used by designated community members.Additionally, the
EpicandFeaturetemplates presently have a section to track child items included in the issue description. This accurately captures our process today but the desire in the future is to implement #325 to leverage GitHub sub-issues to more naturally track these relationships (at which point we'd remove these sections from the template).