Meta: Self-Assembling Organization

[cjslep]

Update: 2019-07

ForgeFed Community Forum

In order to consolidate development and community discussions, there is now a public web forum on the feneas.org website. FeNeAs is a non-profit volunteer organization dedicated to promoting federated networking, such as services and clients using ActvityPub as their federation protocol; and so it is a natural fit for ForgeFed. Everyone is invited to use that forum instead of this GitHub issue tracker or the mailing list for general discussions.

Thanks to FeNeAs for promoting ForgeFed to a primary category and managing the forum.

Web Forum: https://talk.feneas.org/c/forgefed

ForgeFed in the Fediverse

There is also a user on the Mastodon network to which fediverse users can subscribe for progress updates. Feel free to interact with that actor or use hashtag: #ForgeFed on the Mastodon network.

Fediverse: @forgefed@floss.social (https://floss.social/@forgefed)

ForgeFed Repository

This GitHub repo has not been updated in some time, and it is unclear at the moment whether or not @yookoala still wants to maintain it. The NotABug repo contains the most recent documentation and reference source code, all currently under the maximally permissive CC0 license.

Repository: https://notabug.org/peers/forgefed

For the time being, that repo is mirrored as a second repo to this github organization:

https://github.com/forgefed/forge-fed

That is still less than ideal of course, as the previous discussions and external links still point to this repo; but i will try to keep that second one in sync for the time being.

---

Update: 2018-06

Notice about Joining the Mailing List

All: I feel that the mailing list is about the right size to have diversify opinions without making everyone crazy. I think I'm going to set some boundaries for later joiner:

If you are a git service software developer, please introduce yourself here and state that you want to join. If nobody in the current mailing list disagree, we'd add you to the mailing list. If not please keep reading our mailing list archive. Should you want to say anything, please follow up existing issues or create new one.

This is only for the sake of discussion quality. If any mailing list member disagree, we may discuss over the mailing list. And if you're not a member, you're welcome to file a new issue in this issue tracker for discussion.

Thanks a lot.

@yookoala
8th June, 2018
(updated 9th June, 2018)

P.S. Prepended to @cjslep original post. The text below the line is the original content.

---

Meta: Self-Assembling Organization

This is going to get a bit meta, but it is just because I am biased to wanting to see success here.

The first part A is kind of an overview of the different moving pieces I see going on, which others may or may not already be aware of. My intention here is to be informative about the state of this space, not dictatorial/authoritative. Part B is just my bland appeal to interested parties in making this successful in a coordinated fashion.

Part A

Just from the various topics I've seen float around, it seems there's several problems to solve, different prioritization in which to solve these problems, different ideas on what those solutions precisely look like, and (obviously) different parties doing these.

What

• Problem of federated authorization: This was talked about in the #social irc some as mentioned in ask w3c/activitypub how to extend the activitypub protocol #2
• Problem of fitting Git socialization data into the ActivityStreams data model: Mentioned in Need to provide a baseline specification #1. Maybe a part of ask w3c/activitypub how to extend the activitypub protocol #2, also?
• Problem of fitting Git socialization behaviors into the ActivityPub actor model: Also mentioned in Need to provide a baseline specification #1. Maybe a part of ask w3c/activitypub how to extend the activitypub protocol #2, also?

When

• I've seen suggestions elsewhere of rolling out in two phases: First provide data as ActivityStream objects, then work on the consumption side.
• I've seen some prioritize for solving the federated authorization first.
• The Git socialization features would realistically be implemented piece by piece as well, but no timelines until the design is done.

How

• For federated auth, I've seen IndieAuth and ocap-ld suggested.
• For both Git socialization problems, there's things documented in Need to provide a baseline specification #1 and ask w3c/activitypub how to extend the activitypub protocol #2 already.

Who

• SocialWG: Authored the ActivityStream 2.0 Spec, ActivityStream 2.0 Vocab, also maintains the ActivityStream 2.0 terms list, also authored the ActivityPub spec. As well as many others.
• All the git hosting solution providers: Gitea, Gogs, Gitlab, etc
• Other ActivityPub implementors, such as Mastodon, etc
• (Sorry if I missed you!)
• Peanut gallery w/ biased, vested interest (I fall here).

Why
I had a recent back and forth on Mastodon with a skeptic about this effort, so forgive me for not including this at this time. :)

Hopefully the above is informative!

Part B

I'd love for this effort across projects & people to succeed. I would hate to see people left out of conversations, problems not getting enough visibility, or piecemeal solutions adopted.

I don't have a good solution here; I'm new to the self-organizing open source space. Since I am not a part of the SocialWG nor any of the user-facing projects, I also don't know what the right self-organizing communication structure would look like to get buy-in on decisions from everyone.

Part of this appeal stems from seeing issues like #4, part of it is fueled by my raw excitement. Thanks for reading this long post.

[neithernut]

Although you call this "Meta", it does contain traces about what should actually go into a design document:

• A list of stakeholders
• A formalization of the requirements

These would be starting points, rather than the underlying technologies (e.g. ActivityStream) in classical development. I feel they should be clarified rather sooner than later. One of the maintainers could open a PR which would be used for assembling and discussing these basic points. It'll be probably be a mess, but better have the mess now than later, when different expectations and ideas clash in the specification of the protocol or, worse, the implementation.

[Bugsbane]

I also don't know what the right self-organizing communication structure would look like to get buy-in on decisions from everyone.

I'm not saying that it's perfect, or even that I'm highly knowledgeable about it, but take a look at Loomio ( loomio.io iirc) which the Diaspora devs were using to coordinate and work on collaborative governance. I found it a really interesting tool.

[yookoala]

A quick note on point 1 in "What": SNS like Mastodon federates their identity by including the server domain to it (i.e. "yookoala@github.com" for my account here). The same username in different server is considered different users and thus no need to reserve username across federation.

[yookoala]

Anyway, as @bill-auger pointed out in #1, we should have a mailing list for formal work group discussion. Should we use Google Group? Or should we use other notable services?

Potential Members in Work Group

@techknowlogick
@unknwon
@cjslep
@cwebber
@bill-auger

[techknowlogick]

Personally I am against google groups, but not so stubborn, as I would use it if a majority agrees.

I've seen loomio (as mentioned above) used successfully, and would vote for that. Although, as @bill-auger linked to they were able to have these discussions in a git repo, and even Rust-lang uses git repos for their RFCs (example: rust-lang/rfcs#2457), so I also wouldn't be opposed to using this repo for these discussions (all potential members have GitHub accounts currently).

[bill-auger]

google does not have mailing lists - google has "google groups" web forums - i quite literally meant a "mailing list" (as in: i can read and receive messages in my email) (and without clicking my mouse) - it is the most universal communication medium - to any argument of the form: "... but most people already have <?> accounts.", the best answer to <?> is "email"

[bill-auger]

"(all potential members have GitHub accounts"

i would not assume so much - "all potential members" is the entire world isnt it?
all that is evident this far is that all people who have expressed an interest in this group have github accounts - surely, that is no co-incidence as this group has offered no other contact information and is so far limiting all discussions to github

[techknowlogick]

@bill-auger I apologize, the "all potential members" comment was in reference to the list above titled Potential Members in Work Group, not in reference to everyone in the world.

[yookoala]

@bill-auger: Are there any good (and free :-) ) mailing list service out there we might use?

[bill-auger]

off-hand i know of tuxfamily and savannah - possibly riseup or framasoft

[yookoala]

I heard good comments on framasoft's service (Framalistes). If there is no objections, I'd start a list there tomorrow :-)

[theodotos]

You have my vote on Loomio. It is a great platform for taking decisions and managing a project. It can also be self-hosted in case Microsoft buys loomio.org :).

Framasoft is a nice option too.

[ppwfx]

Maybe let's do a voting, one comment per option and everybody thumbs up their preference. Maybe options should be formatted in a standardized way.

Would be nice if each option would provide a one sentence description and how much it costs, as loomio is only free for up to 10 people (wouldn't mind if somebody creates a gitsub patreon to finance it tho)

So far we have

• github
• google groups
• loomio
• framalists

[simon-brooke]

Seriously, folks, letting centralised capitalist entities host our repositories is how we got into this mess in the first place. We need a decentralised, mastodon.social style, federation of nodes, all or most of which are controlled by individual developers.

The bits of this are simple. We need

1. a githook post-commit script that publishes an ActivityPub message with a specified format on each commit;
2. an ActivityPub consumer which reads commit messages from chosen streams and automatically does a pull request - so as to provide backup if the 'home node' of a project goes dark;
3. a search spider which actively seeks out nodes and indexes the projects they host;
4. a search interface which allows users to query what has been discovered by the spider.

It's all simple, we can do this.

[ppwfx]

@simon-brooke how is your comment related to the organisational setup? please open an issue if want to talk about implementation details imho

[bill-auger]

@21stio - how could it possibly be preferable to pay a centralized host and require everyone to sign-up for an account on it (presumably most people have never even heard of that site) merely for the sake of something as simple a discussion - to me that is less sensible than simply continuing to use this issue tracker

dont you see the folly in that? - rather than using email which is federated, costs nothing, and everyone has it setup already - and if for some very peculiar reason, someone does not have email yet (an email address is of course a requisite for both git and github) that person is free to choose their email provider or self-host it

[bill-auger]

simon-brooke's first paragraph is precicely on topic - i was elaborating on that same point myself at the time it went up

@simon-brooke - issue #1 is a discussion about spec proposals - i added there the notabug-2.0/vervis design document - you may be interested to see that most of the work has been done to this end and the vervis reference implementation is nearly ready for demo https://notabug.org/NotABug.org/notabug-2.0

this issue is only about where to find a home for the working-group - i have offered tuxfamily as one option because in addition to mailing lists, they offer full hosting in case folks want some mattermost or other "webby" sort of things eventually - for now, i still content that email is more than sufficient at this early stage

[yookoala]

@bill-auger: I think @21stio meant to pointe out that this thread is not about specification or implementation details. Although @simon-brooke has valuable input, it is not about forming a work group, which is the title of this issue.

@simon-brooke: Couldn't agree more that we want to prevent relying on centralized hosted service. I've proposed to extend ActivityPub precisely because of that. I've specify how it could work in the current draft branch. But in the end, its more important to have enough stack-holders agree on an open standard than my opinion. Feel free to start a new issue to discuss your proposal. And feel free to join the work group mailing list (which would be created tomorrow).

[ppwfx]

@bill-auger

I never stated any preferences. There are mixed opinions on where this should live. Some prefer an ideological biased solution, some a pragmatic. I'd lean towards a pragmatic one but I don't really have an opinion, Im fine with the choice of the majority. It would simply be nice if we would find a consent ASAP.

[pypingou]

👍 to framalist, classic mailing list remain the most accessible mean of communication and discussion in a group.

[bill-auger]

isnt a decentralized git hosting network an ideological solution? and arent centralized git "hubs" the pragmatic solution? so why exactly are we here then, if pragmatic solutions are preferable?

i would not put it in terms of ideology vs pragmatism - its simply dogfooding; and it instills a measure of confidence in outsiders that the organization truly believes what they say and practices what they preach

[ppwfx]

to me pragmatic simply means getting stuff done as efficient as possible, by using stuff everybody is familiar with

and I'd only lean towards a pragmatic solution in the context of project management/communictation at this point in time

I didn't state anything about any other context and any other point in time, with my initial comment I only made a suggestion on how we can have a decision, I'd be very happy if we could end this conversation please

[jaywink]

Personally I would prefer keeping discussion here in one place, until we can move this repo to something that federates. But failing, that, if another communication medium is needed, 👍 to an old traditional mailing list, if such is available for example from framalist. This would be the most neutral and allow for the easiest participation.

Also, I would in theory very much like to participate in the working group, my experience is:

• Previously Diaspora core team member (~2014-2016)
• W3C SocialWG workgroup (that produced ActivityPub) member as invited expert
• Socialhome federated social network author (so I have written a library for Diaspora protocol, planning ActivityPub support)

I'm super excited by this and having federated code hosting has been my dream for years.

[yookoala]

So, I'll try to summarize what we've got so far:

Mailing List

Seems everyone agrees to start a mailing list for future discussion.

Candidates that received active support:

• Famalistes
  Maintained by NPO Framasoft and is free.
  Votes: @theodotos, @pypingou @jaywink
• TuxFamily
  Maintained by NPO TuxFamily and is free. Also has web hosting service.
  Votes: @bill-auger

Decision Making

@theodotos suggested to use Loomio. @21stio stated that the free service supports only up to 10 people. But @theodotos stated that it could be self-hosted. And I believe Framavox, an other Framasoft service, is a self-hosted version of Loomio for people like us to use. (I'm not sure. I can't read French).

I assume that we could use Framavox? (Or is there any alternative?)

Repository Hosting and Issue Tracker

There is strong opinion for moving somewhere other than Github. But no clear opinion has shown where we should be moving to. There is also mild opinion wants to stay here until we get federated service to move to. @Bugsbane and @techknowlogick both feel positive about using it.

The discussion seems to favor moving, so far.
The destination is not decided. Will discuss in mailing list.

Tentative Work Group Members

Someone I think have shown clear interest here in this thread.
Please correct me if I'm wrong.

(alphabetical order)
@bill-auger
@cjslep
@jaywink
@pypingou
@techknowlogick
@yookoala

Potential Work Group Memebers

Someone who has not commented here but have shown interests elsewhere.

(alphabetical order)
@cwebber
@unknwon

[ppwfx]

I'd also like to participate in the Tentative Work Group

[bill-auger]

@jcgruenhage -

the mailing list is world readable - the URL is on the README

[Foxboron]

@bill-auger It is possible to have a whitelisted mailinglist. So everyone can subscribe and only whitelisted people can post towards it. I believe that is what @jcgruenhage wants? Unsure if our current provider allows that.

[jcgruenhage]

@bill-auger I'm sorry, I searched framalists.org for gitpub and it said no results, so I assumed it was private. Thanks for pointing me in the right direction 👍

@Foxboron yep, that would be exactly what I want

[yookoala]

I just want to raise a concern regarding this. You may want to include more people, like software developers with experience using git collaboratively. I'm sure that the developers working on a git service also use that service for their development, but their usage might differ from regular users or might only cover a small subset of the use cases.

@arucard21: I think limiting the members of the mailing list is not the same as closing down the whole discussion from people other than Git service developers:

1. Some people in the mailing list is merely Git users. There are also people from previous ActivityPub specification process.
2. Our issue tracker here is always open to all. So anybody can brainstorm anything, or voice out at any stage of the specification process. Me and other mailing list members are still reading here. And we'll take anything new and insightful here to the discussion.
3. Our discussion archive is open to public. So anybody can read about our discussion and ask questions here.

My main concern, as stated, is the discussion quality. Not hiding from feedbacks.

[yookoala]

It is possible to have a whitelisted mailinglist. So everyone can subscribe and only whitelisted people can post towards it. I believe that is what @jcgruenhage wants? Unsure if our current provider allows that.

@Foxboron: In short, I suck at mailing list settings (cry). If that options exists in Framalistes, I'd love to set that up immediately. Please advice on the procedure to do so. Thanks a lot.

[Foxboron]

@yookoala I sadly have no experience with actually setting one up :/

[arucard21]

@yookoala With the mailing list just being part of the discussion, this seems fair enough. And they are readable by anyone. Perhaps it might help the public part of the discussion to periodically provide updates in the relevant issues in the tracker. Or if something close to a consensus has been reached on the mailing list, maybe then open it up to the public by updating the relevant issue.

But I'm glad to hear that in general you're trying to remain quite open. It's always hard to have these discussions openly and still have them be productive. Perhaps there are some open-source communities that have experience with this. They might have some ideas on at least avoiding some common mistakes.

[yookoala]

@arucard21: I have updated the notice to add link to the mailing list archive. I've also explained how people should use this issue tracker for feedback. I hope that resolved the concerns here.

[Foxboron]

We could write up summaries of discussions, issues and current proposals and stuff them into a git repository. This could either be done weekly, or monthly depending on the activity we end up with.

I know reproducible builds does this and it works quite well.

[yookoala]

@Foxboron: That's a nice suggestion. I think I'll try to do a weekly summary. So the first one should probably come on next Tuesday (?).

[arucard21]

@yookoala

I hope that resolved the concerns here.

It does (to me at least). Thanks.

[ghost]

Hey all, read through comments carefully and meant to subscribe for updates only, not to actively post. I am very interested in this project. No direct work on git-specific services but background in general programming / devops. Would love to follow discussion and contribute if there's a good way for me to do so.

But yeah, just want to subscribe to stay up to date. Apologies if I didn't do that properly. 👍 to discussion around public visibility. I see the list archive is public, but it's much harder to set reminders to check back, so a read-only option for list subscription sounds perfect (with access poss by reaching out to existing members or via gh issues)

Thanks all for this interest and movement. Would love to see this project come to fruition. Obviously necessary

Btw I'm: chris At orghub Dot co

[jaywink]

@yookoala resolved for me too, sorry for the later reply, was sick for a few days ✌️

[LWFlouisa]

I'm curious by what you mean by git developer. With the recent news about Github, I make my own personal hub in Beaker Browser to host my own gits.

But not really sure if that counts. It's not a Github alternative in the traditional sense, as it's largely hard coded rather than "submitted". Or in the blogging world, what they call "Add New Entry."

[yookoala]

@ckuttruff: I tried to make a read-only mailing list for the workgroup mailing list but failed. Don't seem to find a proper solution. If I solve it, I'll add you there. Meanwhile, I'm writing a summary of our discussion so far. Please come back again. I'll post the link to a blog / medium account where you can follow.

[yookoala]

@LWFlouisa: I'm not sure. Seriously. I've read about Beaker Browser but am not familiar with it.

I think to federate your repositories with our proposing federation, you'd need to have:

1. A programable HTTP / HTTPS endpoint for you to expose proper feed (e.g. ActivityStream 2.0 JSON feed or XML) about your repository.
2. Your program to handle external push messages to you (e.g. POST request to your inbox).
3. Endpoint for outsiders to pull / push your repositories.

If Beaker Browser allow you to do all 3. And if you're planning to write a, preferable open sourced, implementation of (2), then I'll consider you as a git service developer.

[ddevault]

Hi, I'm the maintainer of sr.ht, and I would like to subscribe to your mailing list.

[yookoala]

@SirCmpwn: I have just added to the mailing list. Please check if you get the invitation. Thanks for joining :-)

[ddevault]

Thanks! I'll be sending a long and controversial email shortly.

[SoniEx2]

I don't think ActivityPub is the best protocol for this and I don't believe in federating pull requests. I think we should do it more like this: https://cybre.space/@SoniEx2/101858151417423058

[SoniEx2]

like this: https://ganarchy.autistic.space/

[genofire]

PRs and issues are from one instance to another and not back ... so you arrows should not be bidirectional - that will solve it.

[SoniEx2]

those aren't PRs and issues - those are merges/pulls (as in git merge, git pull, git fetch, etc).

in fact I think having PRs is not a good idea at all anymore. they're inherently centralizing.

[SoniEx2]

also this: https://cybre.space/@SoniEx2/101972146630176235

[SoniEx2]

also this https://ganarchy.github.io/

[SoniEx2]

oh and this I guess https://cybre.space/tags/gan385e734a52e13949a7a5c71827f6de920dbfea43

[ShadowJonathan]

@SoniEx2 please dont pollute this conversation by posting multiple links twice, please put them in one message if possible.

I don't believe in federating pull requests.
Please then don't comment on this project, you can safely ignore this project and disable the feature if or when it'd eventually land in gitea, don't sabotage it instead, please.

(in toot)
...notice how there's a lot more cross-pollination...

Personally, I believe that's exactly the right thing, as collaboration bounces around more "evolutionary" between different servers, where different communities are contributing to a "strand" of a particular project, and pull requests therefore can be exactly that "cross-pollination" that betters and adds to each particular version of a project, fixes and features can be shared across all strands of such software.

[bill-auger]

Jonathan - FWIW, there is no more conversation on this issue tracker - it has not been used since about two years ago - if you are interested in forge federation, join the forum: https://talk.feneas.org/c/forgefed