Editorial Sprint

[chunningham]

There has been some discussion and concerns expressed about rehousing the KERI WG. In the interest of maximising cooperation and minimising the potential for divergence, there is a proposal from some WG contributors to focus on collating the KIDs and whitepaper sections into a conventional specification document, particularly the core of the spec which is most unlikely to undergo breaking changes. Ideally, this document can remain compatable with future work. If the group can agree that this document is descriptive and comprehensive enough, it can be ratified into a 1.0 version of the core spec and provide a basis for continued work to contributors who may not wish to participate in future stages of the projects lifecycle.

It is my hope that this proposal can ameliorate concerns about confusion of the status of the project w.r.t. rehousing and spec-maturity as well as prevent divergence in the community and implementations. Concretely, I would suggest that this process take no longer than 6 weeks, ideally just 4, and that this process not prevent any further contribution of any form at any venue.

[bumblefudge]

I/Spruce can commit a few extra hours each week if the WG wants to try for 4 weeks instead of 6 💪

(it sounds altruistic but I'm traveling most of August and none of July so it's actually kinda selfish)

[Joachim16]

Jolocom as well can commit some extra hours

[m00sey]

Are you asking the community to create a normative specification for KERI, under DIF, while there is a proposal in place to leave DIF?

The matter at hand in which is to be discussed in nine days by the DIF Steering committee.

[SmithSamuelM]

It think it would be problematic to split the baby as it were between DIF and ToIP. I don’t see any concrete issues wrt divergence. Divergence only happens if someone decides to fork KERI. Is someone doing that. They wouldn’t be doing that at DIF because the whole point of the discussion of smooth transition was to prevent that. This seems like another attempt to change the rules after the fact that a decision was made.

[bumblefudge]

The proposal is not to split any babies, it's to write SOME of the specS that this WG collectively agreed to collectively write a year ago and never wrote. I've been lobbying for more spec and less whitepaper this whole year, first on behalf of Spherity and now on behalf of Spruce. My agenda has been consistent: spec work is different from code work, and moving the latter endangers the former. I'm trying to protect the former from the latter, and protect everyone's investment without slowing anyone's progress.

Not everyone wants to move ongoing/future work elsewhere, and no one wants to STOP (or even delay) the work continuing elsewhere, but this allows everyone to finish collectively what we all signed up to do here, EVEN IF further design is already happening elsewhere. Seeing everything through the lens of the orthogonal issue of how, when, and with whom "the project" moves elsewhere is counterproductive and prejudicial. No one supportive of this proposal has said anything that would prevent the ongoing prototyping and design work continuing elsewhere. Insinuating that is disrespectful. So is speaking on behalf of "the project" or "the community" when clearly there is not unanimous agreement on the boundaries or best interests of either abstract category.

Would it help to explicitly propose a "feature freeze" and limit the specification work to what was already agreed before the conversation about moving started to create a cleaner firewall between the two efforts? No new ideas, no new design discussions, those can happen elsewhere. We just want to ratify the work of the last year before the baby gets cut in half by a move that is not unanimous. Stakeholders that do not want to move are volunteering to work overtime so that the last year's work is not dissipated or confused by a reorganization that is messy both in adoption, public-messaging, and IPR terms. Retro-specifying what's already done would minimize all those risks and help everyone get what they want out of the work so far and the move.

As for "the" "decision" having "been made", I think you are deaf to facts that are inconvenient to your interpretation of fairly straight-forward documents. I'll continue that discussion in the appropriate thread.

While we're on the subject of charters and rulebooks, I am not happy with accusatory tone in any direction on any of these issues. Please review the DIF Code of Conduct before today's meeting if we're going to be discussing hot-button issues:
https://github.com/decentralized-identity/org/blob/master/code-of-conduct.md#examples-of-unacceptable-behavior-include