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.
Hi Erik,
Do you have a good understanding of *why* there are more issues being
opened than being closed? If so, that might hint at some possible
solutions.
For example, if you just don't have enough people to write code, then
the PMC could focus on inviting new committers to try to grow the
commu
We are struggling with it as well in Apache Airflow.
I can write about some of the things we actively do to try to bring it down
(and we can see how it will work after some time).
We have not succeeded yet (we also have ~800 issues opened) but we for
example have ~130 opened PR and we used to have
they don't know where to start and don't feel that they can even
make a dent in the pile.
Kind Regards
Paul Angus
-Original Message-
From: Jarek Potiuk
Sent: Friday, July 9, 2021 12:51 PM
To: dev
Subject: Re: Issue Management in Apache Projects
We are struggling with
hing).
So I would start by seeing if you have a lot of really old bug reports
and consider closing them as a matter of course. Huge bug lists also tend
to put people of as they don't know where to start and don't feel that they
can even make a dent in the pile.
Kind Regards
Paul Angus
Erik,
>
> My 2c - you (the project) may have to 'take a view' on some of the
> issues if they date back to older versions.
>
> In my experience fixing bugs obviously requires replicating the
> problem, fixing it and confirming that its fixed, but if the issue was
> rep
r monthly triage session could help us
>> start to get some control over the issues filed.
>>
>> Thanks again for all the great advice, and I'm glad to know it's not only
>> us having these issues. We've got some plans in the works to improve this
>> stat
PICNIC - Problem In Chair Not In Computer)
then replicate it in the current version to check that its still a bug,
and _then_ start fixing it...
Volunteers are unlikely to want to take on all that effort, so it does
mean an ever increasing number of old bugs (as Jarek says, only
stakeholders tend t
We've got some plans in the works to improve this
> state, and hopefully in a few months I can follow up on this thread with a
> success story!
>
> Erik
>
> On 2021/07/09 12:01:06, Paul Angus wrote:
> Hi Erik,
>
> My 2c - you (the project) may have to 'take a vie
consider closing them as a matter of course. Huge bug lists also tend to put
> people of as they don't know where to start and don't feel that they can even
> make a dent in the pile.
>
> Kind Regards
>
>
> Paul Angus
>
> -----Original Message-
> Fr
course. Huge bug lists also tend
> to put people of as they don't know where to start and don't feel that they
> can even make a dent in the pile.
> >
> > Kind Regards
> >
> >
> > Paul Angus
> >
> > -Original Message-
> > From: J
PICNIC - Problem In Chair Not In Computer)
>> then replicate it in the current version to check that its still a bug,
>> and _then_ start fixing it...
>> >
>> > Volunteers are unlikely to want to take on all that effort, so it does
>> mean an ever increasing numb
>> > My 2c - you (the project) may have to 'take a view' on some of the
> >> issues if they date back to older versions.
> >> >
> >> > In my experience fixing bugs obviously requires replicating the
> >> problem, fixing it and confirming that its f
13 matches
Mail list logo
