27 May
2024
27 May
'24
3:07 p.m.
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:
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.