[Standards] MIX progress

Dave Cridland dave at cridland.net
Tue Jul 5 09:37:09 UTC 2016

On 5 July 2016 at 10:25, Florian Schmaus <flo at geekplace.eu> wrote:

> On 05.07.2016 11:05, Dave Cridland wrote:
> > On 5 July 2016 at 09:51, Florian Schmaus <flo at geekplace.eu
> > <mailto:flo at geekplace.eu>> wrote:
> >     On 05.07.2016 10:08, Evgeny Khramtsov wrote:
> >     > Tue, 5 Jul 2016 09:55:53 +0200
> >     > Florian Schmaus <flo at geekplace.eu <mailto:flo at geekplace.eu>>
> wrote:
> >     >
> >     >> I'd also welcome if XEP development, especially for such an
> important
> >     >> one like MIX, would be more open.
> >     >
> >     > For the record, we already have github XSF repo for that. We can
> keep
> >     > development there and tag stable version.
> >
> >     So far, the XSF repo is *only* used for submitted XEPs, everything in
> >     inbox/ is a ProtoXEPs and XEPs with numbers follow the standards
> track.
> >     Changes are only made by the XSF Editor Team. It is not used for
> active
> >     development of those XEPs, and I think it should be that way.
> >
> > I sort of agree. I don't see the harm in forking the repository, and
> > working in "pull requests" (which are, after all, just branches).
> That approach would not be visible enough. For one, PRs are not build
> and made available as rendered HTML somewhere. Granted, this eventually
> could be changed. But I still think there is a need for a repo for
> incubating XEPs.
A different repository is a different repository. PRs are just branches.
You're saying that one change cannot be made because it's not as big as the
one you want.

> >     A while ago I suggested establishing an extra repo for incubating
> XEPs
> >     and updates to existing XEPs in xsf at . My vision was to make write
> access
> >     to that repo easily possible, to have it build via CI, and to
> publish it
> >     somewhere (e.g. xmpp.org/lab <http://xmpp.org/lab>), with the hope
> >     that this will encourage
> >     collaboration, improve the quality of ProtoXEPs and kickstart
> >     experimental implementations. This idea was not received well for
> some
> >     reasons I frankly do not understand. We clearly need a place like
> that.
> >
> >
> > I think that would be an admission of failure of what ought to be a
> > really simple process for authors. Write XEP. Publish. Rinse. Repeat.
> > All the way until Draft.
> I believe the current process is seriously flawed and has never worked
> as it was envisioned. So yes, it is an admission of failure. But what's
> wrong with that if the goal is to improve it? People want feedback about
> their XEPs before they are submitted to the XSF. It is as simple as
> that. A we as XSF do not provide them with a tool-chain to support them
> with this venture. Georg Lukas has just recently made the same
> experience, I made with *every single XEP I wrote*.

Until a XEP is submitted it's not an XSF effort. That's by definition, and
it has serious implications on our IPR rules to change that - the
submission process includes copyright assignment, for example.

All you're doing is right-shifting the process, and that'll end up with us
dropping the Draft state because we're going from
Proto->Experimental->Final. This isn't idle speculation, it's precisely
what's happened in the IETF.

Instead, if you think the process is flawed, describe why, and propose
changes to XEP-0001 - don't try to end-run around it.

My suspicion is that the only thing you'd propose changing or removing is
the Council veto for ProtoXEPs, and if this is the case you're welcome to
try. Indeed, I'd positively encourage you to add in guidance, allowable
uses of the veto, an appeals process, and so on. I'd even be curious as to
what removing it entirely would do.

> > I've no particular interest in improving the quality of ProtoXEPs - the
> > quality gate there is next to zero anyway (by intention). The quality
> > gate kicks in at Draft, and we should worry, if anything, about that
> > Introducing more roadblocks to get to Draft doesn't seem useful.
> >
> > Basically, your labs proposal ought to happen, but it ought to be the
> > Experimental state, not some new state beforehand.
> No, please not. IMHO  counterproductive and ultimately harms the XMPP
> ecosystem.

Believe me when I say the previous few months of British politics have
entirely eroded my patience for unsubstantiated claims.

> - Florian
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160705/38e19a50/attachment.html>

More information about the Standards mailing list