[Maildev] Engineering Council or Engineering Steering Committee (ESC) - where art thou?
jorgk at jorgk.com
Fri Aug 31 17:26:48 EDT 2018
On 31/08/2018 22:20, Ryan Sipes wrote:
> Man, this thread has a lot going on! I think having the two issues being
> discussed in this thread doesn't make either single discussion as
> effective as it could be. It makes sense to bring up the HTML editor
> issue insofar as you are pointing out a decision that the module owner
> could make in opposition to what some contributors may want.
> But I think it would be worthwhile to focus on just one of these issues
> in the thread. I'd like to see the conversation around the HTML editor
> play out and see what Magnus, as the module's owner, ultimately makes as
> a decision (if he hasn't already made it). And then move on to a thread
> focused on the ESC and whether or not it is necessary. I think the
> former helps inform the latter conversation.
I started the thread in its many variations on Maildev and tb-planning.
The intent was to discuss the ESC on tb-planning and to given an example
here why conflict resolution is necessary.
In general, the module owner model is the one of a ruling tyrant, even
if they get "buy-in" from others. That's why Kent started a plan to
introduce more decision makers, in fact in a Council meeting it was
voted that four people, technical directors, should become decision
makers for mail/ and mailnews/ issues. The plan was also to establish an
ESC of some form. And that still hasn't happened. You an read it again here:
Currently the situation is that the patch Magnus wants to land is
opposed by Richard, UX submodule peer, and myself, Thunderbird module
and compose submodule peer. So frankly I don't see how, even under the
current rules, the module owner can decide to land something without
sufficient peer review and approval.
For the future I'd like to see a duly empowered panel/committee which
will simply vote, in fact, on any issue, big or small. If in this case
there are more HTML friends than foes, HTML wins, otherwise it loses.
More information about the Maildev