wayland-protocols scope and governance

[Daniel Stone]

Hi Drew,
Thanks for writing this up! I think the broad concept is fine, but a
few things jump out at me:

On Fri, 5 Apr 2019 at 19:43, Drew DeVault <sir at cmpwn.com> wrote:
> I've written up a governance document for us to bikeshed, which is
> included at the end of this email. Some comments upfront.
>
> Logistical notes:
>
> - We'll need a wayland-protocols mailing list. This should probably be
>   members only, to reduce noise.

Hmm, I don't love this requirement, to be honest.

On the members-only front, I think it's important for us to be open
and accessible to new voices, and not create a larger, more
documented, cabal. I think the list should definitely be open to
public discussion and contribution. Especially if we're developing
protocols which are focused on external interaction, we'll want to be
able to have experts from those areas contribute.

On the mailing list front, I think wayland-devel@ is probably quiet
enough these days - and focused on common protocol-like stuff - that
we could probably just reuse that list.

But that being said, I would strongly advocate for doing review
through GitLab. For the implementations and users I can think of -
Chromium, EFL, Enlightenment, Firefox, GStreamer, GTK, KWin, Mesa,
Mutter, Qt, SDL, Weston, wlroots - plus Wayland core itself, all of
them use web review tools (Bugzilla x1, Gerrit, GitHub, GitLab,
Phabricator, Reitveld x1) as their sole review method with the
exception of Mesa, which also allows mailing-list submissions. I get
that sr.ht is working on a decent mailing-list review workflow, but
what we have today with Patchwork definitely isn't that.

There are a few things I dislike about mailing-list review, including
barrier to entry (not subscribed when the patch was sent? you don't
get to participate in review; don't have git-send-mail set up with a
SMTP gateway? you don't get to submit patches at all), built-in
amnesia (easy to lose track of comments made on previous revisions of
patches, or keep track of what has and hasn't been fixed), baroque
tools (git-pw is definitely worse than being able to fetch a real Git
branch), impedance mismatch (losing information e.g. proper ancestry
when posting), as well as ecosystem health (the fd.o Patchwork fork is
only maintained by Intel's DRM team and its upstream isn't
particularly vibrant; sr.ht could be promising but doesn't yet have
wide adoption).

Given that, I'm prepared to push hard for using web-based review as
the status-quo for how we all do our own protocol development anyway.

> - Members will be given push access to the upstream repo. We'll live
>   with a gentleman's agreement to play by the rules and invoke the
>   member removal process if someone doesn't play nice.

That's fine, it's the same as Wayland core: there are clear
expectations and guidelines set in both our CoC and CONTRIBUTING.md,
and you lose your ability to participate if you don't abide by them.

This reminds me that I still need to move the repo hosting to GitLab,
so we can more easily give others access. I've done that now, though
not with issues & MRs enabled.

> - Someone needs to flesh out the website to show adoption and protocol
>   acknowledgement status. Simon was working on something here:
>
>   https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/merge_requests/3

Yeah, keeping going on this would be great. I think it was mainly
blocked on us agreeing what to do here and moving w-p to GitLab as
well.

> In the interest of keeping this effort moving forward, here are some
> actionable tasks we can do, in no particular order:
>
> - Iterate on this document, or propose a new one

I think this document is a good starting point.

> - Establish initial membership and status of each protocol
>   1. State your intention to be a member, including your point of
>      contact and justification per section 1.1, or objection to section
>      1.1's requirements

I think Weston should be a member, and the two obvious points of
contact would probably be myself and Pekka. I have no idea if Pekka is
interested in doing it or not; I would be happy to do it.

>   2. State your project's approval status & statement for any protocols
>      you care about

I'll do that out of band. IIRC the only things Weston would mark
itself as opposed to in wayland-protocols currently are the text-input
protocols (Dorota has much better versions which we'd prefer to use),
and xdg-decoration (not going to implement SSD).

> - Mention any important/interesting implementations of the protocols you
>   care about
> - Decide how & when to ratifiy the new governance model
>
> Aside: wlroots-based compositors have agreed to join under one joint
> membership, but given that this reduces our voting power, we may at some
> point dissolve into our constituent members if necessary. I think in
> practice we'll all get along amicably enough that this won't be a
> problem.

I don't really mind which way you slice it - especially as your
community might diverge enough that Sway holds meaningfully different
opinions from other wlroots-based compositors - but I'd like to avoid
starting off talking about stacking the deck to artificially
concentrate/dilute voting power if it's going to be a block vote
anyway. It's not really the way we'd want to go forward ... :\

>                           1.1. Membership requirements
>
> a. Membership is extended to projects, rather than individuals.
> b. Members represent general-purpose projects with a stake in multiple Wayland
>    protocols (e.g. compositors, GUI toolkits, etc), rather than special-purpose
>    applications with a stake in only one or two.
> c. Each project must provide an individual point-of-contact for that project who
>    can be reached to discuss protocol-related matters.

I'd probably bikeshed this to 'named individuals', so we don't lose
protocol development just because someone's on holiday.

>                             2.1. Protocol namespaces
>
> a. Namespaces are implemented in practice by prefixing each interface name in a
>    protocol definition (XML) with the namespace name, and an underscore (e.g.
>    "xdg_wm_base").
> b. Protocols in a namespace may optionally use the namespace followed by a dash
>    in the name (e.g. "xdg-shell").
> c. The "xdg" namespace is established for protocols useful for implementing
>    desktop-like systems.

I still think 'catch-all window management' is a better definition
here - and I realise now I left this hanging on the other thread,
sorry.

>                       2.2. Protocol inclusion requirements
>
> a. All protocols found in the "xdg" and "wp" namespaces at the time of writing
>    are grandfathered into their respective namespace without further discussion.
> b. Protocols in the "xdg" and "wp" namespace are eligible for inclusion only if
>    ACKed by at least 3 members.
> c. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if
>    if NACKed by any member.
> d. Protocols in the "xdg" and "wp" namespaces must have at least one open-source
>    client implementation & two open-source server implementations to be eligible
>    for inclusion.
> e. Protocols in the "ext" namespace are eligible for inclusion only if ACKed by
>    at least one member.
> f. Protocols in the "ext" namespace must have at least one open-source client &
>    one open-source server implementation to be eligible for inclusion.

This in particular looks great! I'm overall happy with the document,
beyond the couple of nitpicks above and method-of-review discussion
above. I'd also like to see something like Wayland's CONTRIBUTING.md
once we've got this finalised, covering the mechanics of 'how do I
submit my protocol?' rather than the 'how is this project internally
governed?' side, but that obviously isn't a blocker for finalising
governance dicussion. (Could even just start with Wayland's
CONTRIBUTING.md and remove the bits which don't make sense.)

Cheers,
Daniel