27 May
2024
27 May
'24
5:10 p.m.
On Mon, 27 May 2024 14:07:49 +0100
Dave Cridland <dave(a)cridland.net> wrote:
Hey, I happened to notice this discussion buried in
this thread, and
thought it was important to surface it.
On Mon, 27 May 2024 at 09:55, Goffi <goffi(a)goffi.org> wrote:
This seems to also hint at a wider discussion on the XEP process that
has been brought up here and there.
One example recently with many xeps being in experimental while they
are reccomended in the compliance suite and moving them all to stable
which as far as I have seen basically means that changes are rare to
happen and its encouraged to fork the xep instead.
I also have heard that Experimental is supposed to meet some kind of
bare minimmum but as we can see here or with XEPs like xhtml this is
certainly not the case. I have heard of more cases but these are the
ones coming to me now.
My thoughts as I have said before and I think it was proposed
somewhere would be:
- Experimental XEPs shouldnt get a number. Like ietf does.
This means no more "pollution" of the xep number space with random xeps
that went nowhere.
- Council should move to voting only to move to stable. Where xeps get
a number and there is a certain bar to be passed for the XEP to be
accepted.
- We should be much more open to change Stable xeps in the sense of
upgarding them to later versions instead of adding even more xep
numbers to look for. case in point the horrible muc avatar situation
right now.
All this would mean that we can remove at least 4 states for XEPs to be
in with a quick look. Which the states seem to be 11 now for some
reason.
MSavoritias
Of course, a proto-XEP is not meant to be perfect
at first edition;
that's exactly what the experimental status is for. And it's not
the job of the Council to think about side cases - that's what
standards@ and feedbacks from
the whole community are for.
Maybe I got it wrong, but for me, the job of the Council is to keep
technical
stuff on track by ensuring that advancements in XEP statuses are
done in order
(i.e., X independent implementations, Y feedbacks, etc. as stated in
relevant
XEPs), and vetoing things that are really unacceptable (e.g.,
copyright issues, something totally irrelevant, offensive content,
etc.). And it's the
role of the larger community on standard@ to work on technical
stuff, side
cases, ease of implementation, and optimization.
I realize that there isn't a real definition of what should be an
"acceptable"
proto-XEP; maybe this should be specified? Because I've seen
proto-XEPs refused
by some Councils then accepted by others, and this seems quite
arbitrary to
me.
I see Council as doing a finger in the air, human intervention into
the bits of the process we have left - sometimes deliberately -
vague. If you like, Council fills the gaps that are simply too hard
to codify.
Marvin notes the Editor can, and should, catch many of the things
Goffi lists - and that's true, but it is ultimately Council's
responsibility to ensure these are caught. The Editor can't actually
veto; Council therefore must.
But we don't have a set of reasons for veto of proto-XEPs, in
particular, and that's been a highly contentious issue, though
thankfully also a very rare one.
I've rejected protoXEPs as arbitrarily as anyone else when in
Council, but loosely a few things crop up repeatedly:
* Unwarranted duplication of effort: The problem being solved is
already at least partially addressed by an existing solution, and it
seems better to fix that than wholesale replace it.
* Wrong venue: The problem is useful to solve, but needs to be solved
elsewhere (usually the IETF), which has this kind of thing in scope,
and has expertise to help.
* Awful: The problem is being solved in a truly awful manner and I
don't see how it can be fixed without nuking it from orbit and
starting over - or
- the problem is just entirely the wrong problem to solve and should
be nuked from orbit and not started over.
As I spent more time in Council, I tended not to veto protoXEPs for
the latter. I'm not sure this was a good idea - it seemed fairer at
the time, but then you end up with a bunch of people who think the
awful idea was in fact good, and then you have to argue it out at
Last Call which is much more fractious.
The problem is that all of these reasons - and there are certainly
others - are very much personal decisions, and people will entirely
understandably disagree with individual decisions, and even the
process (or lack of it) as a whole. There was a bit of a surge in the
opinion that protoXEPs should be always accepted, a while back, and
I've not been following how this has worked out in practice (and if
it has).
Equally, I've seen other proposals suggesting much higher bars for
accepting a protoXEP, with in effect a pre-Experimental stage tacked
on beforehand. I think this would be bad, too, and risks just
accreting stages for no real benefit - but it's also essentially
inevitable if the bar for accepting a protoXEP is raised too high.
Anyway...
I think it'd benefit the community to have a bit of a discussion on
what they expect from a random Experimental XEP, and also the kinds
of things that can achieve consensus as reasons for Council to veto.
This might result in some process updates - or might just highlight
that we don't want to codify, leaving it to personal opinion.
But I think a discussion would certainly be beneficial. Although also
noisy, sorry.
Dave.