XSF Discussion - 2021-08-24

you like that, or you want something like that?

MattJ, ↑

I don't really care what the new term is, as long as it's more clear. "Stable" seems fine to me. I think there have been other good suggestions in the past.

stable seems really fine to me

sounds like something for the next board meeting ;)

But didn't someone already have a draft patch/PR for XEP-0001?

+1 for s/draft/stable/

not for that I think

I do wonder if there is a better term than 'stable', 'approved'?

but likely most alternatives are better than 'draft'

otoh, I really don't want this to be delayed or even killed by a discussion around the term and our incapability to perform nice polls to get an idea what the community favors

Well, "experimental" has similar problems as well, and if we're going to change them we might as well review them all at the same time

that also sounds like a potential pitfal resulting in an indefinite delay

Well I guess we're unable to make any progress on this issue then :)

Congratulations everyone

Not sure if baby steps can be called no progress

why not s/Draft/Stable/ and discuss about experimental in a separate step

+1

+1

+1 for renaming Draft to Stable ("if it's good enough for the IETF…" argument isn't sufficient, compared to the misinterpretation of the meaning of 'Draft' by almost everyone)

is there an issue with Experimental, given the supposed low bar for entry?

Only when things stay there that are widely implemented

Things get implemented because they are needed or wanted, not because the XEP is finished.

renaming Experimental wouldn't change that

If anything, it could be renamed to something like "In Progress" or something that suggest a work in progress

or "Not Yet Ready for Implementations"

maybe WIP would be more explicit though

"Request For Comments" → "Request For Implementations" → XEP

"why not s/Draft/Stable/ and discuss about experimental in a separate step" +1 to this, what to do about experimental seems much more likely to end in a bikeshed with nothing done

people will implement things on a needs basis, and that's not a bad thing - Experimental is open for _experiments_, precisely to see what works and what doesn't

But it does get awkward when experimental things get deployed to production

🚢 https://github.com/xsf/xeps/pull/1100

(left alone existing XEPs and just changed the text that was output, we can change them later as they get updated or all at once if someone wants to automate that)

Also tooling...

it does, but mandating "you can't deploy this in public" probably won't work; people will do it anyway because they want those features _now_, not in 2 years when the XEP is ready for Draft

Yah, Experimental isn't a problem with the name, it's a problem with how quickly we move beyond that even when features are working well and widely implemented.

a related issue is that Experimental contains both incomplete and ready-for-exploratory-implementations XEPs

And that's basically the big problem with open standards development 🙂

Pacing development of the standards and of implementations while maintaining interoperability ...

there's an easy argument of "if you deploy an Experimental feature and it gets broken, you were warned" (it's not ideal, but that's the reality)

Sam, why did you add Stable instead of s/Draft/Stable/?

jonas’: so that I don't have to update every single other XEP

Just let "Draft" render as "Stable" in the XEPs for now, we can update later as XEPs get updated and not have a massive diff for no reason.

I'd rather have a massive diff than two enum values which mean the same

I disagree, but I also don't really care. I'll drop all the changes except the 0001 ones if you prefer to mess with changing XEPs.

well, the text template should be there, too, I guess that'll be part of what board needs to decide on

the tooling would have to be taught about it anyway

hm

Sam, maybe it makes most sense to *just* adapt the public wording and leave the internal "Draft" identifier the same?

then we have to neither touch all the XEPs nor the tooling

That's just confusing for authors for no reason.

how's that more confusing than having Draft and Stable which both render to the same?

That is not confusing. You copy a template and whether you remember that it's stable or not now it just works.

author's don't deal with Draft anyway

that's editors

If you know you want stable and you enter <status>Stable</status> or whatever and it complains that Stable doesn't exist, that's confusing.

Great, it's confusing for editors then. You may be the only editor right now and be happy with it, but in a few years that may or may not be the same.

better than confusing for authors (which I think the duality would be)

and there's no reason not to update the files in a chore action later to use Stable internally, too ✏

How would it be confusing for authors? They don't even have to know about it, whatever they put in there will just work.

right, maybe not for authors either

Would it affect tooling? Also external e.g. like DOAP tools?

still, introducing an alias is going to cause pain and the other tooling won't be happy about it.

so the sanest way forward to achieve the goal as I understand it ("use stable in [public] communication because it is less confusing than draft") is to just change all the public facing text and let the internal identifier be Draft until we can assess what the impact would be of changing it

Hide it, fiddle with the "warning" text at the top, ???, PROFIT!

pretty much

may also need to do some string substitution in the XSL in the document lifecycle stuff but I assume you did that already anyway

The XSF office hours are in 1.25 hours. There is nothing scheduled, but we could use the call to discuss how to do this if people want to hash it out.

MattJ, poke: https://github.com/xsf/xeps/pull/1099

Sam, as you correctly pointed out that it doesn't affect authors and only editors, I don't think there's much need for discussion. A duplicate enum value is a pointlessly confusing thing, let's just change the frontend texts and leave the enum value alone.

It is not in any way confusing, but sure, as long as someone else is willing to go mess with all the other things that need messing with I'll change my commit to only include the changes to 0001

(done)

XEP-0001 also has the enum stuff and didn't you have updates to the XSL? those make sense to keep…

fwiw, I think a 'stable' xep that in status 'draft' is more confusing

flow, where does anyone see the XML source code, which would be the only place referring to `Draft`?

but sure, if anyone is interested in forklifting the entire tooling right away, be my guest.

i'd imagine that fixing the tooling is mostly also doing something similar to what sam did in his PR

but given that you are the only active editor, I think it's fine if it's your call

also the tooling outside of the XSF?

(think DOAP stuff) ✏

sure

if anything, it indicates to that tooling that the xep state was renamed and that they should act on it

otherwise tooling will continue to label this state as 'draft'

Either way, if anyone's bored and wants to hang out, I figured I'd start the room.

Maybe someone will want to do some live programming or just doodle on the shared whiteboard or something since there are no office hours today: https://socialcoop.meet.coop/sam-pku-dud-niv

I also think we should support finding more editors to support jonas' at core XSF work. I'm happy to propagate through the media stuff we have if thats intended.

Moar hats

I also think we should support finding more editors to support jonas' at core XSF work. I'm happy to propagate through the media stuff we have if thats intended.