[meta] Improve issue management

Created on 1 April 2023, about 1 year ago
Updated 22 April 2024, 2 months ago

Problem/Motivation

A recent Slack discussion indicated that there isn't a single solution for improving the way we work on issues. This issue is to gather all the core issues about that. I hope it will provide one place to see the big picture of what problems people are having and the existing range of possible solutions.

The intention of most of these issues is to make it easier and faster to get an issue resolved and committed. In, other words to remove blockers that are slowing us down. Also included are issues about the Core Gates because they define what must be done for a commit.

I have included any issue I found related to 'issue management'. They do not have to be addressed in this meta but I think it helps to provide the big picture. An example, is the issues in the Coding Standards project about reducing boilerplate documentation.

The issue(s) currently being worked on

This issue is waiting for various manager review and subsystem maintainer review

Related wiki ocumentation

Getting an issue addressed sooner β†’

The issues

Suggested improvements from other issues

From 🌱 [Policy, no patch] Add special tag to identify issues ready for a high level only review Fixed

  • Do more self-RTBCs and keeping issues RTBC after posting changes
  • Another options, 'E' Add status 'In progress' with tag 'Needs architectural review'
  • An approval process (apparantly GitLab has this).
  • More room for 'fixed on commit' from committers.
  • Add a baseline for phpcs.
  • Ignore non automated nitpicks, possible followup. These followup can be good for new contributors. However, there is concern about this due to the credit farming behaviors. Also, longer time to get stable state for new features (from #85).
  • If you find nit-pick standard reviews, then update the patch yourself.
  • Coding standards - remove boilerplate no longer needed

From 🌱 [policy, no patch] Policy to help less interested Patch move forward. Closed: outdated

From 🌱 [policy, no patch] Better scoping for bug fix test coverage RTBC

  • Allow trivial bug reports to be committed without test coverage, when generic test coverage scoped at a wider level, or CS/rector rules would be more appropriate.
  • For non-trivial or low level bugfixes, continue to require test coverage on the issue since in these cases we need be able to demonstrate the bug is fixed without manual testing.

Proposed resolution

As a community work on one of these issues at a time to make incremental improvements. Although, the coding standards issues have a separate process, independent of this meta. They are listed for reference.

Completed

🌱 Plan
Status

Active

Version

11.0 πŸ”₯

Component
OtherΒ  β†’

Last updated less than a minute ago

Created by

πŸ‡³πŸ‡ΏNew Zealand quietone New Zealand

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.69.0 2024