[Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Ian Jackson]

Pirate Praveen writes ("Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED"):
> On വ്യാഴം 01 മാർച്ച് 2018 03:48 വൈകു, Joerg Jaspert wrote:
> > I wonder why you think "a single ftpmaster". We are a team. We closely
> > coordinate what we do and how we do it. When one of us rejects, the team
> > rejects - it just happens to be a random one of us doing it. Others do
> > not need to get involved and review everything. Or we wouldn't ever be
> > able to get anything done if each of us always has to weight in on any
> > single issue.
> 
> Thanks for the clarification. I was thinking about it more like how the
> courts work in India (possibly in other countries too). When a single
> judge decides on a case, there is always an option to appeal to larger
> bench (more number of judges).

For the avoidance of doubt, I don't have a problem with the specific
decision of ftpmaster here.  But I do think that better communication
is essential.

I hope that most REJECTs are accepted by the package's submitters as
being correct, and the problems are fixed.  REJECT messages are
necessarily short.

But when a submitter disagrees with a REJECT, and asks for a review,
IMO submitter is entitled to a longer explanation, and there should
explicitly be an opportunity for other ftpmasters to agree or dissent.

I think this could be easily implemented as follows:

When decision of ftpmaster is challenged by the submitter, or
clarification is requested, the original decisionmaker should write a
draft response and circulate it amongst the ftpmaster colleagues.

After a week or two, if no-one on the team has disagreed, that
response should be sent to the submitter.

The ftpmaster team should explicitly state in its public web pages how
long a submitter should have to wait for such an
explanation/confirmation.  Also they should explicitly state what the
submitter should do if a response is not received.

Finally, final ftpmaster responses should explicitly state what the
correct escalation path is if the submitter still disagrees.

I don't think any of this would be very onerous for the ftpmaster team
to do.  Ultimately in these cases ftpmasters end up having to write
messages like Joerg's.  It would be better to have clearer
communication on a technical level, earlier.

If a particular submitter is causing a disproportionate amount of
work, the situation should probably be discussed with the DPL.

Ian.