[RFC wayland-protocols] Add contribution guidelines for desktop extensions

[Emmanuele Bassi]

[Using GMail, so this is going to be terrible for patch reviewing]

On 22 February 2018 at 08:32, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
>
> I have the feeling that we would benefit from a documented process on
> how to propose cross-desktop extensions. Right now, contributors may
> send a proposal to wayland-devel list only, be met with complete
> silence, and walk away frustrated.
>
> I believe it is wrong to expect Wayland upstream developers to judge
> desktop extensions unless they are also desktop developers. At least
> personally I lack the knowledge to properly evaluate desktop extensions,
> and even if I didn't, I could not speak for the projects who would need to
> carry the actual implementation.
>
> Desktop developers might see wayland-devel as not-our-turf, so it is
> easy to just ignore the emails, and they might get lost between all the
> other traffic there.
>
> To avoid the deadlock silence of "not my concern", I propose we set up a
> guideline to explicitly contact the most influential desktop projects,
> and list their contact information.

Thanks for looking into this, it's very much appreciated.

> Another important part of the guideline is how to formulate the
> proposal. I attempted to write down the question so that it would be
> relatively easy to answer without mandating a considerable review
> effort. Getting the first "good idea"/"bad idea" comments is what should
> get the ball rolling.
>
> Complete review of an extension proposal from multiple parties should
> not be necessary to have the extension land in wayland-protocols as an
> unstable protocol. If projects are in general positive for a proposal,
> it should land in wayland-protocols as unstable. At this stage we would
> expect projects to start picking it up at their own pace (e.g. by the
> original developer submitting implementations), seeing how
> implementations fit them, and propose changes - since the extension is
> unstable, it can be revised freely. However, the requirements for
> declaring an extension as stable should include explicit reviews from
> several projects.
>
> Signed-off-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> ---
>  CONTRIBUTING | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  Makefile.am  |  1 +
>  2 files changed, 64 insertions(+)
>  create mode 100644 CONTRIBUTING
>
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> new file mode 100644
> index 0000000..ab729b2
> --- /dev/null
> +++ b/CONTRIBUTING
> @@ -0,0 +1,63 @@
> +               Contributing extensions for the desktop
> +
> +
> +Wayland-protocols has a requirement for contributed extensions to be generally
> +useful. This excludes extensions that are not expected to be used outside of a
> +single compositor and/or toolkit project. For desktop extensions this means
> +that a proposal needs to have support from multiple projects.
> +
> +When proposing a Wayland protocol extension with the intention to make it a
> +cross-desktop standard in the long run, it may be hard to get sufficient
> +feedback. To help gauging support for the proposal, one should present the
> +following question to the desktop related projects:
> +
> +       Would you accept and merge an implementation of this Wayland protocol
> +       extension, if that implementation met your project's quality standards
> +       and some other projects agreed to do the same?
> +
> +This question avoids the pitfalls of demanding work from others, like
> +demanding them to carefully review your proposal or demanding them to
> +implement or promising to implement it. Such demands are often ignored due to
> +priority reasons. Instead, the point here is to get an acknowledgement on
> +whether the proposal is a good idea.
> +

My main worry is that "acknowledgement" seems to imply "merge as is
(plus or minus quality standards)", but no mention is made about
feedback on design.

I fear that cross-posting to a dozen mailing lists is going to make
discussion and feedback problematic from the perspective of the people
proposing a new protocol, as well as people commenting on it. Having a
single place for discussions would be a good thing; that's typically
what the wm-spec list was meant to be used for, back in the EWMH days.

Maybe we should resurrect the wm-spec list for Wayland protocol
discussions, now that EWMH discussions are not "hot" any more, and use
the list of addresses below as a mechanism to contact interested
parties and direct them to wm-spec — if we want to avoid every person
involved even tangentially to toolkits and Wayland compositors to
subscribe. Unless, of course, you want all discussions about Wayland
protocols to happen on wayland-devel, which would be equally good to
me, but may escalate the traffic on the list.

Before you answer my questions: I'm fully aware that you have kind of
outlined a process in the commit message, but it's probably worth it
to have the same process outlined in the document that people are
going to read. :-)

> +The proposal with the above question should be posted to all of the below to
> +gather sufficient attention. The list in alphabetical order:
> +

> +       GNOME
> +               (contact missing)

For GNOME Shell:

  gnome-shell-list at gnome.org
  https://mail.gnome.org/archives/gnome-shell-list
  requires subscription to avoid moderation queue

> +
> +       GTK+ toolkit
> +               (contact missing)

For GTK:

  gtk-devel-list at gnome.org
  https://mail.gnome.org/archives/gtk-devel-list
  requires subscription to avoid moderation queue

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]