Using GitHub (beta) projects in our workflow

Core Development
1

A while ago GitHub introduced a new and improved version of their “projects”, called “beta projects”. The new iteration support some of the features that we had in Roundup, so I asked them to enable them for the python org. In next couple of weeks, they will also enable another feature that allows editing and triaging issues directly from projects in a side-pane.

You can find an introduction to beta projects on the official docs (includes some images and gifs): Quickstart for projects (beta) - GitHub Docs

Some of the most interesting features are:

  • Support for multiple views, with different sorting/grouping/etc.
  • A configurable table view, similar to the default issue list of Roundup
  • A kanban-style view
  • Custom project-specific fields
  • Workflow automation (e.g. moving closed issues to the “done” column)

I created a couple of projects as an example to give you a better idea:

  • Release and Deferred blockers · GitHub for release and deferred blockers, with
    • a list view, grouped by “Type” (a custom field), showing title, type, assignees, linked PRs, and labels
    • a board view, with a column for Release blockers, and a column for Deferred blockers.
  • Subinterpreters · GitHub for subinterpreters, with
    • a list view to list all subinterpreter-related issues
    • a board view with the status (I put them all on the “Todo” column)
    • a few more list views for bugs/features/docs/C-API
    • a list view grouped by assignees

They still lacks some automations (see readmes in the settings) – I’ll set them up when I get a chance. If you want to play around you can create additional views and experiment there without altering the current views (and then possibly delete the view). Also be careful not to alter the issues since they are real issues from the python/cpython repo.

A few caveats:

  • This is a beta feature, so it’s subject to changes at any time.
  • New beta projects must be created from the python org page, and then added to the python/cpython repo through the “Projects” tab of the repo.
  • The max number of issues in a project is currently 1200
  • If you create a regular “old-style” project, there is currently no way to convert it to a beta project

A few more things:

  • GitHub - actions/add-to-project: Automate adding issues and pull requests to GitHub projects (beta) can be used to automatically add issues with certain labels to specific projects (e.g. issues with the expert-subinterpreters to the Subinterpreters project)
  • You can also include PRs, and issues from other projects
  • When you add an issue to a project, the project will be listed in the issue sidebar
  • Apparently you can also create personal projects/views under your GitHub user, and add the issues you care about using python/cpython#XXXXX (this doesn’t affect the issue sidebar)
  • From the issues tab of the repo, you can select multiple issues using the checkboxes on the left, and add them all to a project from the “Projects” dropdown (on the top right, just above the issue list)
  • You can create custom project-specific fields such as module (of a package) or priority, so that the issues can be further classified within the project
  • You can use view to replace certain Roundup queries, including filtering, sorting, and grouping – but it will only apply to issues already in the project
  • You can use projects instead of (or in addition to) meta-issues, to track multiple related issues

You can give them a try and see if you find them useful. Different teams or people can create different projects and manage them in whatever way works best for them. If you have any question or feedback, you can ask here or ping me directly.

6 Likes
2

On top of the projects listed above, @storchaka and @erlendaasland have now created a number of beta projects for several modules/areas of the stdlib. You can see them here:

Some notable examples that showcase how to use projects effectively:

For smaller projects, creating a “meta-issue” that uses a task list (About task lists - GitHub Docs) is also an option.

We are also discussing other changes in our workflow, including replacing all the expert-* labels with projects, but there are still a few features we need from beta projects before doing the switch (most notably the ability to follow projects and be notified when an issue is added to the project).

These are still experiments as we try to figure out what works best – once we do we will document it in the devguide.

2 Likes
3

One argument in favour of still keeping the expert-* labels, is that they make it very easy to distinguish issues in the issue search; the labels stand out visually, projects does not even appear (yet).

1 Like