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

[Emil Velikov]

Hi Pekka,

On 22 February 2018 at 08:32, Pekka Paalanen  wrote:

> +Once there is sufficient cross-desktop support for a proposal, the Wayland
> +maintainers can accept the extension into wayland-protocols.
> +
Might be worth defining "sufficient" in a bullet point somewhere.
Say, "more than 1 of the mentioned projects", or "50%+1", "2/3", etc

HTH
Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [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  wrote:
> From: Pekka Paalanen 
>
> 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 
> ---
>  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 000..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 

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

[Pekka Paalanen]

From: Pekka Paalanen 

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.

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 
---
 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 000..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.
+
+The proposal with the above question should be posted to all of the below to
+gather sufficient attention. The list in alphabetical order:
+
+   Enlightenment
+   (contact missing)
+
+   EFL toolkit
+   (contact missing)
+   
+   GNOME
+   (contact missing)
+   
+   GTK+ toolkit
+   (contact missing)
+   
+   KDE
+   (contact missing)
+   
+   Qt toolkit
+   (contact missing)
+   
+   Wayland development list
+   wayland-devel@lists.freedesktop.org
+   https://lists.freedesktop.org/mailman/listinfo/wayland-devel
+   requires subscription
+   
+   XDG development list
+   x...@lists.freedesktop.org
+   https://lists.freedesktop.org/mailman/listinfo/xdg
+   requires subscription
+
+Note, that Wayland upstream maintainers cannot in general help with getting
+desktop extensions approved. The buy-in must come from the desktop projects,
+both server and client side, themselves. No-one can force them to accept an
+extension. Wayland upstream is merely a gatekeeper to wayland-protocols
+repository.
+
+Once there is sufficient cross-desktop support for a proposal, the Wayland
+maintainers can accept the extension into wayland-protocols.
+
diff --git a/Makefile.am b/Makefile.am
index 4b9a901..5fe46a7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -33,6 +33,7 @@ nobase_dist_pkgdata_DATA =