Because we decided to build an executable specification for ActivtyPub at Human-Connection: https://github.com/Human-Connection/Nitro-Fediverse
I think more projects might benefit from the cucumber features, you just have to implement your own project-specific step definitions.
By the way: We’re meeting bi-weekly on Thursday 1pm UTC (15mins from now):
FWIW, “resurrected” is not quite accurate - the project never ceased - what happened was that the initial design discussions pretty much ran their course after a few months - the remaining work to be done is primarily in prototyping - there was simply not as much to discuss publicly for that period - so, one could get the impression that the work had stalled if only watching the mailing list
furthermore, if one was only watching the github repo, the impression would be that almost nothing had ever been accomplished - that was a case of the default “BDFL” management structure of a github repo working against the effort far more than it was helping - most notably because the no-derivatives license on the github repo literally prevents anyone else from working on it - the repo owner thwarted our every attempt to change the license to something more permissive; so that the efforts of peers community and others could be included in the github repo (ideally as a mirror of the notabug repo) - unfortunately he never gave anyone else write access to the repo, nor moderation rights to the mailing list; and he has not interacted with the mailing list nor github repo in over six months - that is why there is still nothing but a README in that repo
though it apparantly attracted a lot of interest, that github repo and mailing list had no potential to become anything more than discussion forua, because no one participating in the discussions agreed that their work would be published under a no-derivatives license - that was added to the github repo very prematurely by the repo owner before any discussions began, most importantly, before any discussions regarding an acceptable license began - it was one of the first issues raised, the consensus was unanimus that it needed to be changed; but that did not happen - so once the initial discussions had run their course, there was nothing more that could be done on github or the mailing list, other than posting occasional updates on how the general interest was taking form in various places and about similar discussions in other venues such as this one
to be clear, fr33domlover and the peers community had been discussing and working on repo federation for years before the “git-pub” discussions last summer; of which, the name ‘ForgeFed’ was the one tangible item agreed upon by consensus - those of us who wanted to continue the actual work beyond those hastily “knee-jerk” motivated discussions, had no option other to continue the work on notabug (plus IRC) as we had been doing all along - beyond engaging the new crowd of interested people in discussion, the most that we could do in those venues was to invite those who are interested to the IRC channels and the notabug repo where the license allows open collaboration - that was the primary reason we contacted them in the first place - if i had known that the license would never be changed, i would have stopped right there - other than meeting folks from a few other related projects such as social-home and git-dit, the most useful information we got from it, is that a lot of people wanted forges to support activity-pub - activity-pub was already considered to be a viable option for the inter-op communication layer; but we were not aware of how popular it was
now that the prototyping is coming to fruition, we are considering to open a new web-based discussion forum, perhaps on this server, as a replacement for the github issue tracker, which is associated with an now apparently defunct repo
the other thing i would like to underline, is that it is not at all important whether or not gitlab or any other forge upstream is willing to implement ForgeFed interoperability - the free software licenses of the mature self-hosted forges (e.g. gitlab, pagure, gogs/gitea and several others) fully permit anyone who is interested to write that implementation - endorsement by the upstream is not required and is of no particular value to self-hosting admins or their users - reference implementations in python and ruby are planned, that would ease implementation in pagure and gitlab - if someone wants to make one in PHP and/or golang, that would cover the majority of the mature self-hosted forges
Thank you for setting me straight Bill. And for shedding light on the efforts over the past year. Glad to hear things have been moving, and I have also had the pleasure to talk to fr33domlover in the socialcg IRC room in the interim.