I'm likewise following Russ's advice and moving this to -project alone.
I've had some time to reflect on this, and wanted to offer the following
thought.
On Wednesday, April 03, 2013 13:13:48, Chris Knadle wrote:
> On Wednesday, April 03, 2013 09:40:50, Ian Jackson wrote:
> > Chris Knadle writes ("Re: [all candidates] Removing or limiting DD
> rights?"):
> > > On Tuesday, April 02, 2013 13:53:24, Ian Jackson wrote:
[…]
> > > > Of course if a maintainer inappropriately adopts such an aggressive
> > > > approach to bug triage when it isn't necessary, you can appeal to the
> > > > Technical Committee. I doubt the TC would want to set out a decision
> > > > overruling a maintainer's workflow (and in any case it's hard to see
> > > > how such an overruling resolution could be made practical).
> > > >
> > > > So if you want to do this, you will need to assemble a team to take
> > > > over the package and ask the TC to depose the maintainer(s). But
> > > > wouldn't it be better to volunteer to join the team for the package,
> > > > and help out the maintainer cooperatively ?
> > >
> > > Starting off with a maintainer that closes my bug report with no
> > > explanation at all?
> >
> > If you and your allies have enough time and knowledge to help with the
> > package, then yes, you can certainly help with this.
> >
> > You could write to the maintainers:
> > I notice you closed my bug without comment, so I went to take a look
> > at the rest of the bugs for gnomovision. You do indeed seem to
> > have a bit of a bug overflow crisis.
> >
> > I asked Alice for help; we took a look at the list and you'll see we
> > have followed up with triage or status changes to a few of the open
> > bugs which had the most obvious next steps.
> >
> > Please let us know whether this was useful. Would you like us to
> >
> > carry on with some of the less obvious bugs ? For example:
> > #739130 probably needs to be reassigned to splurge-piper
> > #739312 looks like a mips toolchain bug, will RFH to the mips porters
> > ...
I've reconsidered the above suggestion and I think it would give positive
feedback for the maintainer doing the wrong thing.
It's based on making /assumptions/ of why the maintainer closed the bug
without discussion -- the entire problem is that we don't know the
maintainer's reasoning, because it wasn't given. Unfortunately, being
overloaded is /not/ the only reason maintainers do this -- based on behavior
I've seen, another reason this is done is when the maintainer doesn't want to
discuss the issue behind the bug at all, and is thus an act of dismissiveness.
I'd like to /think/ that this is a special rare case, but there's no way to
know without having more communication in each case.
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
Attachment:
signature.asc
Description: This is a digitally signed message part.