wayland-protocols scope and governance

[Drew DeVault]

Sorry for the delay, catching up on my emails now. Responding to Daniel
as the other emails don't have much actionable stuff, but I read
everything on this thread. Thanks for the feedback!

On 2019-04-08  6:18 PM, Daniel Stone wrote:
> 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.

Alright, let's drop the members-only requirement.

> 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.

-1, it's way too noisy imo.

> 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.

I'll begrudgingly concede to patch review on Gitlab, even if it's 10x
more work to get your patches out there. I think that discussions ought
to stay on a mailing list, though. It's just a better medium for them,
and everyone has an email account.

> 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.

I'll guess I'll just formally register a strong NACK, but I feel like
I'm shouting at a tree.

I know it's hard to turn a blind eye to my vested interests in mailing
list driven development, but even on GNU mailman I prefer mailing lists.
There's a reason I built my platform that way, after all. I genuinely
think it's a better model.

> > 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.

+1

> > 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.

Will reword this a bit for the v2.