On Mon, 27 May 2024 14:07:49 +0100 Dave Cridland <[email protected]> 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 <[email protected]> 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. 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 _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
