>>>>> "Roberto" == Roberto C Sánchez <robe...@debian.org> writes:
Roberto> On Thu, Jul 04, 2019 at 10:18:18AM +0200, Raphael Hertzog wrote:
>> On Wed, 03 Jul 2019, Roberto C. Sánchez wrote:
Roberto> The point of Debian being a do-ocracy is not lost on me.
Roberto> In fact, when it comes to technical matters, it is the
Roberto> superior approach. Even in difficult technical matters
Roberto> (like the init system debate) where the choices amount to
Roberto> "do this" and "do nothing" there is a technical committee
Roberto> which can act as arbiter. However, when it comes to
Roberto> non-technical matters, esepcially when one potential course
Roberto> of action is "do nothing," there is no such possibility.
Roberto> Those who wish to "help" marginalized groups by displays
Roberto> such as the pride month support have an avenue to "do" what
Roberto> they believe is best in this do-ocracy of ours. What
Roberto> course is available to me and those like me who believe we
Roberto> should "do nothing"? It would seem that public discussions
Roberto> that attempt to address that are met with great resistance
Roberto> and with many attacks against the character, motivations,
Roberto> and demographics of those who hold that position.
Hi.
So, first, if you want to have more influence in a given team, join that
team and contribute active work to it. I don't think anyone here is
saying that the teams in question shouldn't exist. So, even if you
think the right option for a given issue is "do nothing," there are
positive things you could do to gain credibility within the teams in
question.
Different teams have standards for how they evaluate concerns raised by
members. But if all the concerns here were being raised by active
members of the publicity team who contributed ongoing time, I'd expect
the team to treat them seriously.
If you are not willing to dedicate the time to a team, you have less
influence, but there are still cases where project-level concerns
matter.
According to constitution section 8.3 delegates should attempt to follow
consensus opinion. That means they have latitude to not follow
consensus opinion in some cases, but I think it would be reasonable for
us to carefully consider such situations.
That is, I think it would be unusual for a delegated team to act when
there is a project level consensus against their proposed action. I
think it would be unusual for a delegated team not to adjust their
future actions in response to a project consensus to do so.
Of course, when we speak of consensus, we're almost always talking about
some rough consensus model. You could rarely get a consensus of any
kind with a full consensus (positive support, no one at all raising an
objection they consider blocking) with the project as a whole.
I think that because of the strong presumption that teams have
significant latitude, you'd need a fairly strong project level consensus
to counter that presumption.
The discussion of supporting Pride Month has not reached a rough
consensus that the publicity team should act differently under any rough
consensus model we're likely to consider plausible. (The question of
whether there is a consensus in this discussion in favor of their
actions is more complex, but that is not the question that matters.)
If you are unable to get a consensus, you have a few other options:
* You can talk to the delegates about your concern.. You probably should
have done this before the big consensus discussion anyway, but I'm too
lazy to rearrange my message.
* If the DPL becomes convinced that delegates decisions are too far out
of sync with the project's needs, the DPL can adjust the members of
the team. The DPL cannot overturn a specific decision, but alignment
between project goals/needs and the goals/needs of the current
delegate absolutely is something the DPL can consider when changing a
delegation. In this instance, I support the publicity and diversity
teams.
* You can attempt to get sufficient support behind a project level
policy. That could be done by consensus too, although if you failed
to get sufficient support on a single issue, you might not have so
much luck there. But you might have enough support to bring a
proposed policy to vote in a GR. Delegates are not strictly bound by
any such policy, but again, they *should* follow them. And it would
be reasonable for the project and DPL to remove delegates who
routinely ignored policy without adequate justification. A GR
establishing non-technical policy only requires a majority to pass;
that's not going to be enough to be a consensus, but in some ways
votes are more binding.
* And of course you can propose a GR trying to overrule the specific
action or changing the delegation.
I think those are your options in a situation like this.
I hope that gives you a sense of empowerment. Even if you cannot get
sufficient support on this issue, there's a clear path by which if a
team got too far disconnected from what the project wanted it could be
adjusted.
--Sam
