PRs in Triaging/Backlog/Sprint

[kenodegard]

State of Affairs

• Issues are automatically added to the triaging board and is lead through triage and into the backlog during the team's refinement
• PRs are ignored in this process, we do not require triaging & labeling PRs

Where do PRs belong within our Triaging/Backlog/Sprint process?

Proposal 1

Require all PRs to have an associated issue that has been triaged and refined.

Pros	Cons
PRs are simply "handled" by existing processes	Barrier to entry
	Contributors don't care about our planning process

Personally, I feel this has too high of a barrier to entry and hence should be ruled out.

Proposal 2

New Kanban board for PRs.

Pros	Cons
Clean distinction between an issue and a PR	Defines a whole new process
	Who is responsible for monitoring/moving PRs through the board

Proposal 3

Improve PR templates. Offer 4 PR template flavors:

• Linked Issue: A template based around there being an existing Issue that has already been triaged
• Bug Fix: A bug fix template for a contribution that doesn't seek to resolve an existing Issue
• Feature Implementation: A feature implementation template for a contribution that doesn't seek to resolve an existing Issue
• For conda-core Only: A blank template with a blurb stating that if any non-conda-core users use this template that the contribution will be immediately rejected (this is probably unnecessary since we should (?) assume that any conda-core PR will have had a proper issue opened ahead of time)

Pros	Cons
Ensures all contributions include full background info	Barrier to entry (but it feels lower than Proposal 1)

[kenodegard]

Rolled out a new Planning board that includes a view for open PRs, this effectively implements proposal 2 above.

[kenodegard]

We will continue experimenting with the new Planning board but otherwise, this has been completed.

Additional work should be done to roll out consistent issue/PR templates for all repos.