wayland-protocols scope and governance

[Simon Ser]

> Here's an updated governance document for everyone to consider. Changes
> from the first version:
>
> - Use wayland-devel instead of a dedicated mailing list
> - Use Gitlab for reviewing new protocols
> - Extend discussion period for governance amendments from 30 days to 60
> - Permit either 1 or 2 points of contact for a wayland-protocols member
> - Clarify who's affected by the cool-down period after a failed
>   membership removal vote
>
> I chose not to change the wording of the xdg namespace definition,
> despite Daniel's objection. I couldn't come up with a wording that I
> think would make everyone happy - feedback welcome. Under Daniel's
> proposed wording of "catch-all window management", a case is easily made
> for wlr-foreign-toplevel-management:
>
> https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml
>
> I expect this would be controversial. Or perhaps it wouldn't be, and
> would fit into this namespace, but would just be NACK'd by some folks.
> Depends on how strongly integrated desktop folks want to gatekeep the
> XDG namespace. Thoughts?

The wlr-foreign-toplevel-management is a subset of xdg-shell the other way
around. Similar controversial protocols are virtual-keyboard and input-method:
those are tied to wl_keyboard and text-input but are for "special clients".

I'm not sure what's the best definition of "special client". What I mean by
"special client" is that "regular clients" shouldn't need access to those
protocols. In other words, regular clients don't need to manage windows, provide
an input method mechanism or simulate keypresses.

Maybe we can narrow it down to "unprivileged window management" instead of
"catch-all window management".

Note that the wp definition ("protocols generally useful to Wayland
implementations") is ambiguous in the same way.

Thoughts?