Problem

There is currently a significant backlog of issues and PRs, many of which aren't well organized. I'd like to help improve this.
To that end, I'm seeking feedback from others - hence this issue.

Organizing the backlog was also mentioned by the OP in Proposal: Future of this crate.I believe it's worth starting this process before the next branch merge, since this kind of organizational change can be done independently of the code base - assuming the system is flexible enough to adapt to future needs.

Plan

Issue/PR Labels

I would suggest the Topic-Subtopic system for Issue labeling. Specifically, something similar to what’s already partially in place with labels like:
C-new-algorithm or C-proposal (Category: A new graph algorithm and Category: Proposal, respectively).

However, I think several useful categories are currently missing. Therefore, I would suggest the following system/labels.

List of labels

Each label suggestion is of the form:
Emoji for the color (subject to change of course) Topic-Subtopic: Label description text

🟡 A-benches: Area: Benchmarks
🟡 A-ci: Area: CI
🟡 A-docs: Area: Docs
🟡 A-readme: Area: Documentation that isn't part of any crate such as README.md or CONTRIBUTING.rst
🟡 A-petgraph: Area: Petgraph crate functionality

🔵 C-bug: Category: Bug
🔵 C-new-algorithm: Category: A feature request for a new graph algorithm
🔵 C-feature-accepted: Category: A feature request that has been accepted pending implementation
🔵 C-feature-request: Category: A feature request
🔵 C-performance: Category: A change motivated by improving speed, memory usage or compile times
🟣 C-proposal: Category: A proposal and request for comments
🔵 C-question: Category: User questions that are neither feature requests nor bug reports
🔵 C-tracking-issue: Category: An issue/PR that collects information about a broad development initiative

🟢 P-easy: Call for participation: Experience needed to fix: Easy / not much
🟢 P-medium: Call for participation: Experience needed to fix: Medium / intermediate
🟢 P-hard: Call for participation: Experience needed to fix: Hard / a lot
🟢 P-help-wanted: Call for participation: Help is requested to fix this issue

🔴 S-needs-triage: Status: Needs to be labelled
⚪ S-blocked: Status: Marked as blocked ❌ on something else such as a PR or other implementation work
⚪ S-blocked-on-msrv: Status: Need an MSRV bump to progress
⚪ S-breaking-change: Status: Need a breaking change release to progress
⚪ S-nominated-to-close: Status: A contributor thinks this PR or issue should be closed out
⚪ S-waiting-on-author: Status: Awaiting some action by the PR/Issue author (such as code changes or a rebase)
⚪ S-waiting-on-review: Status: Awaiting review from the assignee but also other interested parties

This might be expanded by a Topic like M- (Module) once petgraph is split up into independent sub-crates. These additional labels could however also be added to the A- section.

Also I thought about whether there should also be labels for 0.8.x. and 0.9.0 releases or whether that should simply be handled by milestones? Probably milestones makes more sense, since otherwise these systems would be redundant.

This suggestion is inspired by two large and well-maintained crates: Tokio and Bevy.

Please let me know what you think of this suggestion as a categorization system for the issues/PRs. Do you like the proposed system? Do you think some categories are redundant/unnecessary? Is something missing? Do you have strong opinions on coloring?

Issue/PR templates

In addition to the labeling system I would suggest revamping the PR/issue template (or create one for the latter). Again, inspiration comes from Tokio and Bevy, both of which use clean and helpful issue/PR templates.

I would particularly see a benefit in using such a system for PRs that want to merge new algorithms. Templates could clearly communicate expectations, such as including an example in the docstring, theoretical and empirical/actual runtime, and the relevancy of tests and quickchecks (if applicable).

Also, issues/PRs could automatically be labelled accordingly with the above system.

Overall, this could make reviewing and contributing to issues and PRs more efficient and consistent. While there's some initial overhead in setting up and using such a system, I believe the long-term gains in maintainability, clarity, and contributor experience will more than justify the effort.

Implementation of plan

If there's agreement on the general direction and details, I'm happy to start implementing this plan. For that I would create the issue labels and create PRs for the templates. I'd then go through the existing backlog and apply appropriate labels. For this, the 'S-nominated-to-close' label could be particularly useful, since I could nominate some issues to be closed and other Contributors/Members could give their opinion on whether an issue should actually be closed or not.