Replies: 1 comment 1 reply
-
Hey @elikling, may I bring in a slightly different suggestion? I'd like to follow an approach inspired by the approach presented here: https://alloverse.com/2022/05/31/github-projects-for-open-source-tracking/. The reason is that I wouldn't want to assume a fixed set of people. Contributors come and go, and that's normal for an open source project. So using columns for contributors wouldn't work too well I believe. Also, people can be assigned to tasks or issues through the assignee property of an issue. Instead, I would recommend using GitHub Projects in the way they're intended, with some of the hacks suggested in the link above. I'll go ahead and create some epics (some of which you also listed). |
Beta Was this translation helpful? Give feedback.
-
Motivation
As the number of people contributing and taking interest in PyWhy is growing there is a desire to provide some structure to communicating what is being worked on and in what stage it is.
The Kanban board provided by Github is a grate way to run daily stand-ups within a work-stream discussing the resolutions of issues and bugs. It feels too detailed to serve the weekly Discord call.
Suggested board approach
There are two possibilities to choose from for a high level "state of the project" review:
The PBIs (Product Backlog Items) can start of as notes which is decided, can be turned into issues that to be monitored in Kanban style boards.
As the board is used, the incorporation of pull requests can be explored.
The Devil is in the detail
The 2022 capability of managing a project alows for several view tabs. In the table view, it is possible to define a new field:
Name: Challenge
Type: Single select
Values: {
}
Beta Was this translation helpful? Give feedback.
All reactions