Meta: Self-Assembling Organization
cjslep opened this issue · 91 comments
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 #2
- Problem of fitting Git socialization data into the ActivityStreams data model: Mentioned in #1. Maybe a part of #2, also?
- Problem of fitting Git socialization behaviors into the ActivityPub actor model: Also mentioned in #1. Maybe a part of #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 #1 and #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.
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.
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.
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.
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
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).
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"
"(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
@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.
@bill-auger: Are there any good (and free :-) ) mailing list service out there we might use?
off-hand i know of tuxfamily and savannah - possibly riseup or framasoft
I heard good comments on framasoft's service (Framalistes). If there is no objections, I'd start a list there tomorrow :-)
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.
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
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
- a githook post-commit script that publishes an ActivityPub message with a specified format on each commit;
- 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;
- a search spider which actively seeks out nodes and indexes the projects they host;
- a search interface which allows users to query what has been discovered by the spider.
It's all simple, we can do this.
@simon-brooke how is your comment related to the organisational setup? please open an issue if want to talk about implementation details imho
@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
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
@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).
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.
👍 to framalist, classic mailing list remain the most accessible mean of communication and discussion in a group.
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
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
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.
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.
I'd also like to participate in the Tentative Work Group
FTR, I have no opinion b/w framalist or tuxfamily, mailing lists are mailing lists, I don't really care where they are hosted :).
framavox is also a potential option, never used it so I can't provide feedback but I'd be willing to give it a try, I just don't know if it is something that can integrate well in a email-based workflow or if I'll need to keep a tab open with it.
people are eager and in a rush to begin then frama is probably the best option if only because frama stuff is more like a self-service buffet o' goodies; so activation is probably automatic - the tuxfamily folks are more of a community who like to get to know the member projects - most of their services you need to ask someone to turn it on for you - that level of care is preferable of course for a long term host but it may delay creation of the mailing list by a day or 2
i would suggest starting the mailing list on frama today AND establishing a relationship wtth the tuxfamily community to discuss hosting options for the long term - the mailing list could always be changed to tuxfamily at some later time - the only benefit to switching later would be the matching domain name
Hi there, I just came across this from the gitlab federated discussion. I'm interested in being involved here as I could see this being the future home of OSS projects. I don't have experience with SocialWG or ActivityPub, or even writing specifications. I've just been writing code for a couple decades and can help with that. Is there room for me here?
For the discussions/proposals format, I'd think prioritizing using one's own platform would be key. So after this federated git thing is built, using that. And before it's ready, anything that ports/exports easily to it would work (so anything using git + branch review like pull/merge requests + issue tracking). So, using something like GitHub or GitLab until this thing is ready, then importing the entire git history and using the new thing. It'd be nice to have the full history intact.
I'm abstaining from providing input on the choice of tools -- I defer to those more experienced & opinionated than I.
I do want to emphasize @bill-auger's point about people being very enthusiastic about solving problems already. It's pretty impressive, and I hope spirits stay high. However, these quick-moving discussions also show the need for a decision-making process. It looks like Committee Voting? (We sure we don't want a BDFL? Hehe, j/k) Who are the stakeholders that get a vote? A vote per person, or per project?
Then the questions about thresholding. First Past The Post (50%, 2/3)? Single Transferrable Vote? Ranked ballots?
Or is this too formal, and we just play it by general consensus?
What about simply staying here for now. A lot of people already starred and are watching the repo, link juice is building up, everybody knows the tooling and has an account..
What feature are we missing here (besides federation)?
+1 for staying here. And in regards any possible voting (bound to happen :)), I would favour for example voting with +1/-1's in the issue as reactions to a proposal, or some other way in writing. Voting in meetings excludes those who can't participate at that particular time.
I just found this thread and am catching up but I like the direction this group is headed and would like to be added to the Tentative Work Group.
+1 for staying here. As it stands GitHub is the de facto home for OSS projects and collaboration. I know we are all itching to change that, but the momentum of this project is building around this repository. Once we have a viable alternative, as @bill-auger pointed out, dogfooding will be important to instill a sense of confidence in the community.
That said, I'm happy to collaborate via whichever medium those with more experience decide best meets the needs of this project.
@cjslep: I think it makes sense to have one vote per project. But in reality, I don't think there's a reasonable way to decide who get to vote for a large open source project. So that would be hard to implement.
I personally prefer to have general consensus as the default resolution method. But I do think we need a way to vote when undecided. So I'd prefer to have a tool to cater for such situations. And in such situations, I think it makes more sense for people to vote only if they have participated in the discussion. So a simply "+1" and "-1" in Github comment might be too chaotic for management.
So I'd rather we have a voting platform setup for people who joined our mailing list. And probably a simple majority (50%) vote? What do you all think?
A quick update.
Mailing List
I have created a mailing list on Framalistes. And my email is koalay at gmail.com. I have closed down public subscription there. I hope people who join the group would at least introduced himself here.
I think I managed to find email address for @cjslep and @techknowlogick but not everyone else. Please send me a email and state your Github user name in it. I'll add you all to the 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)
@21stio
@bill-auger
@cjslep
@coderkevin
@cwebber
@jaywink
@pypingou
@samheutmaker
@techknowlogick
@yookoala
Welcome to join later anyway.
Decision Making
Since people are very enthusiastic towards the federation idea, I think we need to setup some voting mechanism quickly before all the inputs get out of hand. I'm proposing to use Framavox for voting in the future. I think this should be our first general consensus discussion in the mailing list.
+1 for staying here. And I personally suggest 66.67% vote. 50% agree could mean argument points are even on both sides (even could potentially have three and more sides on one idea).
this repo does not need to go away - no one is suggesting that - you will probably need a place to hold the documents - the mailing list is for discussions - that is what mailing lists are for - this is a bug tracker - it could surely be left open for the purpose of pull requests; but most are in agreement that the group should get its own website soon anyways - i honestly can not understand the inertia against migrating the discussion to email
the mailing list has been created and the majority have already agreed that is the most universal communication tool that will invite the most participants - if the discussion stays on github you are guaranteeing that only github users will be in the discussions; which is extremely mis-aligned with the goals of this group
@unknwon: Thanks. I've found your email on your Github profile and I've just added it to the mailing list.
I'm also interested in the working group. I'm a lousy coder but can help with sysadmining and testing. Can I be added in the mailing list too?
@theodotos: Sure. I might be an even lousier coder :-)
Just send me an email so I know your email address. My email address is marked on this comment.
@yookoala could you please add me as well to the ML (jroquet@arkanosis.net)? Thanks!
@Arkanosis: Just added. Please check your mailbox to see if you received the invitation from Framalistes.
@unknwon: The Framalistes backend said that your email at gogs.io is bouncing. Please check if you got the invitation. If not you'd probably need to give me another email address. Just send me a mail to koalay at gmail.com to discuss. Thanks.
Yo.
Interested discussing and helping the effort. Experience with semantic technologies and vocabularies from University, along with a lot of git experience and avid programmer. Would be awesome to be added to the mailing list for further discussions. morten@linderud.pw
Got it. Thank you :)
Can I be added to the ML? Also interested in helping / discussing wherever possible. hello@benjaminbaedorf.eu
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)
@unknwon: I've checked the bouncing message. Our mailing list server got "550 Mail content denied" from QQ's mail server. It could be just spam filter or it could be something else entirely. Do you have any extra mailbox (e.g. say, Gmail?) that we can contact you with? Thanks.
Hi there, this repository has been pointed to me on our chat room.
For your information, I've worked on decentralized tickets and merge-requests system based on XMPP and it's already working (cf. https://www.goffi.org/b/9555cc02-6a87-4b6b-af85-20f1c0736722 and https://www.goffi.org/b/F4xScokjZejCYAB4NamBbc/decentralized-code-forge,-based-xmpp). In other words, there is working basis for decentralized code forge.
It's not restricted to Git (we are using it with Mercurial), and it's possible to do gateway to existing plate-form.
You can ping me if you wants more details.
there was another team saying much the same about their "decentralized" tools yesterday - rather than repeat myself about how decentralization is necessary but insufficient for federation; i will point you to this thread where some possible workflows were discussed
#11 (comment)
there has been a fervour of discussion over the past few days you may want to read everything on this issue tracker to decide if your tools are a good match for a fully federated system - even if not, im sure you have some good ideas - feel free to express them
Please add me also to mailing list
lafriks -
firstly, you did not give your email address - so adding you to the list would be quite impossible
but more importantly, yookoala has stated that the list should remain as small as possible but large enough only to have enough diverse opinions and backgrounds - you would really need to give some description of your qualifications and specific interest in the group
His mail address is stated in his profile. And it appears that he's a Gitea contributor. It would still have been nice if this was stated by himself rather than requiring some investigation.
Sorry for not giving more detailed info, I was on mobile phone :) So as said in previous comment. yes my email address is what is in my GitHub profile page. I'm Gitea contributor and currently one of owners.
EDIT: I did subscribe to mailing list using lafriks-AT-gitea.io email address, I hope to correct one :)
@lafriks: Just add your another email to the mailing list. Please check your mailbox and see if you get the invitation. Thanks for joining.
I think I have received emails, I've added sender to whitelist.
@unknwon: Nice! thanks.
If you are a git service software developer, please introduce yourself here and state that you want to join.
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.
Of course, to keep quality of the discussion high you should still try to ensure that they have sufficient knowledge about git, git services, federation techniques, usage and modification of standards and protocols, etc. Some of this knowledge doesn't even require a developer to be familiar with git or git services at all. For example, I'm sure you'd want someone who helped create ActivityPub to be included in the discussion, even if that person has never used git or any git service before.
I hope that this diversity of knowledge and experience can help create better git federation. Best of luck to you all.
Disclaimer: I'm not a git service software developer but I also don't need to join the mailing list. So I think I can be fairly objective about this.
there is a discussion of those concerns on the mailing list now
i will add that the constraint you mention was added only after the group was already at significant size
I think it's sad if the group decides to work in private and ignore public feedback. I would encourage, even if it adds noise, to either allow discussion here (by not actively discouraging it) or allow anyone to join the mailing list. For example the SocialWG had two mailing lists, one for public comments, one for group members. There has to be a way for the "public" to give feedback, otherwise it's not an open specification worked on openly, and that risks ignoring valuable feedback from someone who had some.
I realize noise is a problem but hiding from it is the wrong answer :)
that is the very reason this github issue tracker was left open for comments - it says so on the README now
I have to kinda agree with @jaywink here. It would be nicer if the mailing list was publicly accessible. If noise is the concern, make it so that only some people can post, but everybody can join and read.
I'd be really interested in reading the discussions here, whether or not you people think I'm qualified to do so.
the mailing list is world readable - the URL is on the README
@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.
@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
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:
- Some people in the mailing list is merely Git users. There are also people from previous ActivityPub specification process.
- 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.
- 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.
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.
@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.
@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.
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.
@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 (?).
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
@yookoala resolved for me too, sorry for the later reply, was sick for a few days ✌️
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."
@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.
@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:
- A programable HTTP / HTTPS endpoint for you to expose proper feed (e.g. ActivityStream 2.0 JSON feed or XML) about your repository.
- Your program to handle external push messages to you (e.g. POST request to your inbox).
- 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.
Hi, I'm the maintainer of sr.ht, and I would like to subscribe to your mailing list.
@SirCmpwn: I have just added to the mailing list. Please check if you get the invitation. Thanks for joining :-)
Thanks! I'll be sending a long and controversial email shortly.
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
like this: https://ganarchy.autistic.space/
PRs and issues are from one instance to another and not back ... so you arrows should not be bidirectional - that will solve it.
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.
also this https://ganarchy.github.io/
oh and this I guess https://cybre.space/tags/gan385e734a52e13949a7a5c71827f6de920dbfea43
@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.