I find that assigning work is better done outside of Apache. As a committer triaging bugs, the committers to whom you might assign those bugs don’t work for you. (Of course, you and they might work for the same company. But when you are both wearing your Apache hat, no one works for anyone else. I call it the “pushing on a rope” problem of open source software development.)
I have worked for “commercial open source” companies that employ engineers to maintain Apache projects, and maybe Superset has a similar situation. We had our own triage process and system for assigning work to engineers. It mostly works well, but people need to take care to follow the Apache Way: for example, design discussions need to happen on-list even while you are making assignment decisions off-list. And developers working on features need to remember to create a public issue before they start work, not just when they submit the pull request. While it’s problematic to assign work when you are wearing your Apache hat, one thing you can do is triage: assign labels and priorities to issues, so that committers (or other contributors) can self-assign based on those labels and priorities. For example, you could assign a label “must fix next release”, or “must back port to the maintenance branch of the previous major version”. (Inevitably, a few folks in the community will notice that these labels have great power, and start applying them to their own issues, but that’s a solvable problem.) Julian > On Jul 8, 2021, at 2:03 PM, Erik Ritter <erik.t.rit...@gmail.com> wrote: > > Hi all, > > I'm a PMC member for Apache Superset, and we've recently been struggling > with the number of issues reported in our Github repo. We're currently at > > 800 open issues, and are having trouble keeping up with responding and > addressing all the user issues and feedback. We were curious if any other > Apache projects had a way of managing Github issues that works for them. We > were considering setting up a bot that assigns new issues to a random > committer/PMC member, but are open to other ideas too. Thanks for your help > and advice! > > Best, > Erik Ritter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
