On 05.07.2016 11:37, Dave Cridland wrote: > On 5 July 2016 at 10:25, Florian Schmaus <f...@geekplace.eu > <mailto:f...@geekplace.eu>> wrote: > On 05.07.2016 11:05, Dave Cridland wrote: > > On 5 July 2016 at 09:51, Florian Schmaus <f...@geekplace.eu > <mailto:f...@geekplace.eu> > > <mailto:f...@geekplace.eu <mailto:f...@geekplace.eu>>> wrote: > > On 05.07.2016 10:08, Evgeny Khramtsov wrote: > > > Tue, 5 Jul 2016 09:55:53 +0200 > > > Florian Schmaus <f...@geekplace.eu <mailto:f...@geekplace.eu> > <mailto:f...@geekplace.eu > <mailto:f...@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.
Yes. > You're saying that one change cannot be made because it's not as big as > the one you want. No. > > A while ago I suggested establishing an extra repo for incubating > XEPs > > and updates to existing XEPs in xsf@. 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> > <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. We start to talk about two different topics here. One is a repo for incubating XEPs which has an "powered by XSF" sticker on it. And the other is about the life-cycle process of XEPs. I think I already explained substantially why I believe such an incubating XEP repo would be great. And about the other process: Maybe carbons (XEP-0280) is a good example. It's one of the five XEPs I consider crucial for XMPP's future (the other one being SM, CSI, MAM, and maybe MIX). It's been in last call for nearly a year. I've not heard much from the authors. I also saw no interest from them to progress the XEP. Of course, that's perfectly fine and I don't blame them. In open standard and open source work, nobody is obliged to do anything (unless you get paid for it maybe). But as far as I know, we have no policy how to handle this. And thus, a critical building block of XMPP technology is in a state of suspense and makes no progress. Is carbons the only example? No, we have 8 XEPs in last call. Some of them for years. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
