Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
Ian> Thanks for your mail. I have trimmed vigorously the parts I
Ian> agreed with :-).
Thanks again for your mail.
I also trim parts where I think we understand each other and seem to be
in general agreement.
I want to explicitly call out your analysis of how mailing list
discussions can be problematic.
I think that's a really important point to this discussion.
I might choose to be less formalized in how I'd prefer to solve the
problem.
However I think you've highlighted that mailing list discussions are the
wrong approach for the really thorny issues.
One mechanism that is often helpful in cases where mailing list
discussions add value is to summarize them going forward.
I think we're very close to a point where it would be useful for me to
prepare such a summary of this discussion.
>> I also think the court emphasis on justice and "right" is
>> harmful. As I said in my blog entry, technical correctness is an
>> important factor, but I think it is a less important factor than
>> maintaining our community.
Ian> IMO injustice _itself_ undermines community.
Ian> When you say you want to put "community" ahead of "justice",
Ian> what I hear is that you want to put the opinions of some people
Ian> ahead of others, because they might be hurt more if the
Ian> decision goes against them, or because the are more important
Ian> to the project somehow.
Ah, thanks for explaining what you heard. That's not what i want to say
at all.
Also, I wouldn't even say I put community ahead of justice. I put
community ahead of technical correctness. I also think court-style
justice in our community would emphasize technical correctness. Justice
as an abstract concept is not something I have simple positions on.
Ian> After all, if we are not to put some people's opinions ahead of
Ian> others, what we are left with is making decisions based on the
Ian> merits, which is what I am thinking of as justice.
This statement feels wrong to me. It's not obvious to me why it is true
that the putting some opinions ahead of others is coupled to making
decisions on the merits.
I think there's possibly more to unpack there, although I'm not sure
it's where we need to go to understand each other.
I'd like to give some examples of cases where I think community is more
important than technical correctness.
* Some people's opinions do matter more than others on some decisions.
The most obvious example of this is we have a culture of letting the
people doing the work have huge latitude. It might be better overall
if we picked a single scripting language for all Debian
infrastructure, maaintainer scripts, development tools, archive
software and the like. It's far more important to let the maintainers
use the tools they prefer. It might have been great for the project
to mandate debhelper a while ago. Just within the last year we've
finally gotten to a point where policy recommends using debhelper in
one circumstance. Again, we strongly prefer letting people doing work
have flexibility. So often, the TC finds itself saying "you might
even be right about the technical issue, but those folks actually
doing the work get to pick in this instance."
* Sometimes respect for work going on or for process is more important
than technical correctness. You and I have disagreed about specific
instances of the past. But for example I believe that if the policy
editors are unsure whether they reached consensus on an issue, one
significant factor that the TC needs to consider is whether the policy
team did or did not reach consensus under their internal policies. I
understand we disagree on the specifics here, and this is probably the
wrong forum to rehash that. I do think that cases where respecting
what other people are doing and respecting other processes are more
important to community stability than technical correctness.
* pSometimes it is more important to have maintainers or maintainer teams
who are good at bringing in new people, mentoring, and the like even
if it frustrates technical experts. If a particular maintainer team
consistently has trouble dealing with their stakeholders, I think
making changes to improve communication can be appropriate even if it
decreases the technical quality of the team for a while. None of us
are so good that we cannot be replaced, and yet all our contributions
are valued.
* Sometimes it is more important to get a decision made than to have the
perfect decision. This needs to be balanced against manipulating the
processes to prevent stakeholders from contributing etc.
* Sometimes the cost of reviewing a decision can be higher than any
potential gain. I can think of a number of TC bugs where a lot of
frustration was spent overriding a maintainer and there was little
benefit to our users. It was the right decision from a pure technical
standpoint, but it really didn't end up mattering.
I suspect we'll still disagree somewhat, but I think we may be closer
there than my original message implied.
I think our key disagreement is that you prefer formalism and I prefer
to agree on principles and trust in people. I don't think persuading
each other will help much there. I think we understand the tradeoffs of
these two views of the world, although if you don't think that's the
case I'm happy to dive into that.
I think this might be a case where letting whoever actually does the
work pick the balance is the only thing we can do. It's not clear that
either you or I will actually be putting together a new TC process, so
we don't know who should make that decision.
Reply to: