<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 July 2016 at 10:25, Florian Schmaus <span dir="ltr"><<a href="mailto:flo@geekplace.eu" target="_blank">flo@geekplace.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05.07.2016 11:05, Dave Cridland wrote:<br>
> On 5 July 2016 at 09:51, Florian Schmaus <<a href="mailto:flo@geekplace.eu">flo@geekplace.eu</a><br>
</span><span class="">> <mailto:<a href="mailto:flo@geekplace.eu">flo@geekplace.eu</a>>> wrote:<br>
>     On 05.07.2016 10:08, Evgeny Khramtsov wrote:<br>
>     > Tue, 5 Jul 2016 09:55:53 +0200<br>
</span><span class="">>     > Florian Schmaus <<a href="mailto:flo@geekplace.eu">flo@geekplace.eu</a> <mailto:<a href="mailto:flo@geekplace.eu">flo@geekplace.eu</a>>> wrote:<br>
>     ><br>
>     >> I'd also welcome if XEP development, especially for such an important<br>
>     >> one like MIX, would be more open.<br>
>     ><br>
>     > For the record, we already have github XSF repo for that. We can keep<br>
>     > development there and tag stable version.<br>
><br>
>     So far, the XSF repo is *only* used for submitted XEPs, everything in<br>
>     inbox/ is a ProtoXEPs and XEPs with numbers follow the standards track.<br>
>     Changes are only made by the XSF Editor Team. It is not used for active<br>
>     development of those XEPs, and I think it should be that way.<br>
><br>
> I sort of agree. I don't see the harm in forking the repository, and<br>
> working in "pull requests" (which are, after all, just branches).<br>
<br>
</span>That approach would not be visible enough. For one, PRs are not build<br>
and made available as rendered HTML somewhere. Granted, this eventually<br>
could be changed. But I still think there is a need for a repo for<br>
incubating XEPs.<br>
<span class=""><br></span></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>     A while ago I suggested establishing an extra repo for incubating XEPs<br>
>     and updates to existing XEPs in xsf@. My vision was to make write access<br>
>     to that repo easily possible, to have it build via CI, and to publish it<br>
</span>>     somewhere (e.g. <a href="http://xmpp.org/lab" rel="noreferrer" target="_blank">xmpp.org/lab</a> <<a href="http://xmpp.org/lab" rel="noreferrer" target="_blank">http://xmpp.org/lab</a>>), with the hope<br>
<span class="">>     that this will encourage<br>
>     collaboration, improve the quality of ProtoXEPs and kickstart<br>
>     experimental implementations. This idea was not received well for some<br>
>     reasons I frankly do not understand. We clearly need a place like that.<br>
><br>
><br>
> I think that would be an admission of failure of what ought to be a<br>
> really simple process for authors. Write XEP. Publish. Rinse. Repeat.<br>
> All the way until Draft.<br>
<br>
</span>I believe the current process is seriously flawed and has never worked<br>
as it was envisioned. So yes, it is an admission of failure. But what's<br>
wrong with that if the goal is to improve it? People want feedback about<br>
their XEPs before they are submitted to the XSF. It is as simple as<br>
that. A we as XSF do not provide them with a tool-chain to support them<br>
with this venture. Georg Lukas has just recently made the same<br>
experience, I made with *every single XEP I wrote*.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Instead, if you think the process is flawed, describe why, and propose changes to XEP-0001 - don't try to end-run around it.</div><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I've no particular interest in improving the quality of ProtoXEPs - the<br>
> quality gate there is next to zero anyway (by intention). The quality<br>
> gate kicks in at Draft, and we should worry, if anything, about that<br>
> Introducing more roadblocks to get to Draft doesn't seem useful.<br>
><br>
> Basically, your labs proposal ought to happen, but it ought to be the<br>
> Experimental state, not some new state beforehand.<br>
<br>
</span>No, please not. IMHO  counterproductive and ultimately harms the XMPP<br>
ecosystem.<br></blockquote><div><br></div><div>Believe me when I say the previous few months of British politics have entirely eroded my patience for unsubstantiated claims.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- Florian<br>
<br>
</font></span><br>_______________________________________________<br>
Standards mailing list<br>
Info: <a href="http://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">http://mail.jabber.org/mailman/listinfo/standards</a><br>
Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org">Standards-unsubscribe@xmpp.org</a><br>
_______________________________________________<br>
<br></blockquote></div><br></div></div>