- From: Jacopo Scazzosi <jacopo@scazzosi.com>
- Date: Sun, 27 Feb 2022 20:35:16 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>, Kingsley Idehen <kidehen@openlinksw.com>, Henry Story <henry.story@gmail.com>
- Cc: public-webid <public-webid@w3.org>
Hi all, > I support your generous offer to handle editing of this spec. > [...] Good luck! Thank you Kingsley! > +1 as new editor Thank you Melvin! > Typically community groups can make structural changes with 4 > approving votes, which I believe you've had > I think role of Editor is to reflect consensus of the group and > listen to objections While thresholds are necessary to ensure that progress can be made, I am going to try to listen and work on convergence as much as I can. > It might be worth having two drafts. One which tries to fix issues in > the current draft, which might have various stakeholders, with some > resistance to change, And one new spec, that is simple and less > constrained, as time allows. I'd rather focus on building consensus and admit defeat if I am not successful than work on two different drafts, potentially encouraging divergence. > Please not that CSarven has helpfully put forward 3 PRs to the > repository recently, > [...] Those are simple and easy to agree with. Yup - I have opened https://github.com/w3c/WebID/issues/9 to reach as many of us as possible. > The current document has had 10 years of consensus, so it’s really > up to those seeking changes to make their case, and we’d like to make > sure we are moving consensus forward, not putting everything in question. Henry, thank you for voicing your skepticism. It gives me the chance to write a bit more about how I am looking at this, which I've been invited to do as a way of introducing myself a bit better. I acknowledge that WebID has had a long life, that plenty of discussion has already taken place and that any and all further editing efforts should be mindful and respectful of those that have already been spent on it. However, the spec has yet to outgrow its draft state. I intend to honor past efforts by contributing my best at crossing the gap from draft to final, producing a spec that stands a concrete and practical chance at achieving widespread use. It appears to me that quite a lot of case-making is taking place around issues of practical relevance and that further consensus is slowly building, at least based on the exchanges I have been a part of and those that I have been reading about. This growing consensus does revisit some past choices, undoubtedly informed by the experience accumulated since the first days of FOAF+SSL, and the changes are significant enough that I would be more comfortable addressing them as I described rather than purely incrementally. Given how long the spec has remained in its current state, I think that questioning previous decisions and assumptions is not only a reasonable thing to do but also a desirable thing to do, **as long as the outcome continues to embody the spirit of the specification itself**. That said, if any of you should find any part of my offer to be a categorical no-go, be it what I am proposing as a foundational starting point and/or my approach to editing, please let me know (either here or privately). My offer is just an offer, and my goal for this thread is to gauge your support, as a group, for what I am offering. I’ll wait a day or two so that others will have a chance to pitch in. Best regards, Jacopo. --- Jacopo Scazzosi https://jacoscaz.com https://treesandrobots.com
Received on Sunday, 27 February 2022 19:35:32 UTC