Hey, I happened to notice this discussion buried in this thread, and thought it was important to surface it.
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.