#30 Status

Open
opened 1 year ago by davidak · 3 comments
davidak commented 1 year ago

I love the idea of this project and follow it's development since i know about it.

A Status section in the README would help to quickly see how far the development is. It could include a Roadmap with checkboxes.

It would also be interesting how many people are actively contributing (core team).

Also, how the different forges (GitLab, Gitea, ...) are committed to this. Add a short paragraph to each project. I think of something like "We plan to implement this when the spec is final and have 2 members contributing to the spec development".

Also link to Mastodon there: https://floss.social/@forgefed It's a great ressource for updates!

I love the idea of this project and follow it's development since i know about it. A **Status** section in the README would help to quickly see how far the development is. It could include a Roadmap with checkboxes. It would also be interesting how many people are actively contributing (core team). Also, how the different forges (GitLab, Gitea, ...) are committed to this. Add a short paragraph to each project. I think of something like "We plan to implement this when the spec is final and have 2 members contributing to the spec development". Also link to Mastodon there: https://floss.social/@forgefed It's a great ressource for updates!
bill-auger commented 1 year ago
Collaborator

we wanted to keep the README lean as possible - it was once much more verbose; and much of it was moved into separate documents in the docs/ dir, and much of it (the history section) was deleted entirely

a complete roadmap would be too much for a README, and not even appropriate - the purpose of a README is to describe "what this is"; not "what this wants to be" - there are dedicated tools for defining a roadmap which are more appropriate, such as the "milestones" feature of an issue tracker - currently, the list of open issues on this tracker is itself, serving loosely as the roadmap - we could utilize it's "milestones" feature for the quick progress overview though - its not a bad idea; except that currently, it would probably simply include every issue on the tracker into single "milestone"

likewise, the list of contributors is readily accessible in the git commit logs - i dont see a real need to put that information anywhere else either - both the list of tasks and the list of contributors are already easy to find and read

i dont know how to answer to this request:

 "We plan to implement this when the spec is final
  and have 2 members contributing to the spec development".

who do you presume is "we", and why do there need to be 2 contributors?

the only forge that any of "we" make is vervis; which is being used as the test-bed forge - forgefed is being implemented in vervis feature-by-feature, in tandem with the formalizing of the spec

the forges that are most likely to see forge-fed implementations are all free software projects - as such, no one is "committed" to anything; and no one should expect anyone to be - free software is made on a "labor of love" basis - that is, you get the features that the upstream developers want, or you join the team to propose and/or implement the features that you want, or you fork the project and implement the features yourself - it is not of much importance, whether or not the upstream developers are committed to any particular goal

myself, i may implement for pagure; because that is the forge that i would prefer to use for myself, and i am fairly confident that my contributions would be accepted upstream - it is likely that gitea would also; but it is not likely that a team member of any forge is going to implement forge-fed themselves - i would not expect them to either - it is a significant amount of work, and federation is not a stated goal nor within the core feature-set of any existing forge, other than vervis

anyone who would like their favorite forge to support forge-fed can implement it - as long as the implementer freely shares the changes or the fork; then people can benefit from it - that is the most likely way for each specific forge to become forge-fed compatible - it is not necessary for the upstream to accept patches; and it is not very important whether or not they are interested - this repo would be a fine home for those patches or forks, if the upstreams do not take them

we wanted to keep the README lean as possible - it was once much more verbose; and much of it was moved into separate documents in the docs/ dir, and much of it (the history section) was deleted entirely a complete roadmap would be too much for a README, and not even appropriate - the purpose of a README is to describe "what this is"; not "what this wants to be" - there are dedicated tools for defining a roadmap which are more appropriate, such as the "milestones" feature of an issue tracker - currently, the list of open issues on this tracker is itself, serving loosely as the roadmap - we could utilize it's "milestones" feature for the quick progress overview though - its not a bad idea; except that currently, it would probably simply include every issue on the tracker into single "milestone" likewise, the list of contributors is readily accessible in the git commit logs - i dont see a real need to put that information anywhere else either - both the list of tasks and the list of contributors are already easy to find and read i dont know how to answer to this request: ``` "We plan to implement this when the spec is final and have 2 members contributing to the spec development". ``` who do you presume is "we", and why do there need to be 2 contributors? the only forge that any of "we" make is vervis; which is being used as the test-bed forge - forgefed is being implemented in vervis feature-by-feature, in tandem with the formalizing of the spec the forges that are most likely to see forge-fed implementations are all free software projects - as such, no one is "committed" to anything; and no one should expect anyone to be - free software is made on a "labor of love" basis - that is, you get the features that the upstream developers want, or you join the team to propose and/or implement the features that you want, or you fork the project and implement the features yourself - it is not of much importance, whether or not the upstream developers are committed to any particular goal myself, i may implement for pagure; because that is the forge that i would prefer to use for myself, and i am fairly confident that my contributions would be accepted upstream - it is likely that gitea would also; but it is not likely that a team member of any forge is going to implement forge-fed themselves - i would not expect them to either - it is a significant amount of work, and federation is not a stated goal nor within the core feature-set of any existing forge, other than vervis anyone who would like their favorite forge to support forge-fed can implement it - as long as the implementer freely shares the changes or the fork; then people can benefit from it - that is the most likely way for each specific forge to become forge-fed compatible - it is not necessary for the upstream to accept patches; and it is not very important whether or not they are interested - this repo would be a fine home for those patches or forks, if the upstreams do not take them
fr33domlover commented 1 year ago
Collaborator

@bill-auger, I appreciate your detailed paragraphs and summaries, but I also must admit, I don't have enough spare mindspace to keep track of them and update stuff. Idea: We keep the detailed stuff here in the repo, and in parallel make a nice little website rendered right from the source found in this git repo, where people can get info in a visually nicer way (it's hard to navigate with the eyes through the long paragraphs).

@davidak, we'll hopefully have a website soon and have the info more easily and clearly visible. Right now (2 Oct 2019) it's pretty simple: I'm doing the speccing itself (and getting advice from fediverse developers very often) and developing Vervis (used for demos and prototyping). There's some work on GitLab as you perhaps saw on the fediverse, but idk its status. The bottom line is, no forges are implementing ActivityPub right now AFAIK, and I'm working on the spec and on my own implementation. Federation in GitLab CE, maybe WIP, I'm hoping to hear good news about that ^_^

As to how close the spec is to announcing the first official draft: To be honest, hard to say. On one hand, most of the text hasn't been written yet. On the other hand, a lot of technical issues have been already tackled and discussed. The only roadmap item is that after Push activities I'll do federated patches and merge requests. Idk yet what's next, I guess I should make a roadmap ^_^

@bill-auger, I appreciate your detailed paragraphs and summaries, but I also must admit, I don't have enough spare mindspace to keep track of them and update stuff. Idea: We keep the detailed stuff here in the repo, and in parallel make a nice little website rendered right from the source found in this git repo, where people can get info in a visually nicer way (it's hard to navigate with the eyes through the long paragraphs). @davidak, we'll hopefully have a website soon and have the info more easily and clearly visible. Right now (2 Oct 2019) it's pretty simple: I'm doing the speccing itself (and getting advice from fediverse developers very often) and developing Vervis (used for demos and prototyping). There's some work on GitLab as you perhaps saw on the fediverse, but idk its status. The bottom line is, no forges are implementing ActivityPub right now AFAIK, and I'm working on the spec and on my own implementation. Federation in GitLab CE, maybe WIP, I'm hoping to hear good news about that ^_^ As to how close the spec is to announcing the first official draft: To be honest, hard to say. On one hand, most of the text hasn't been written yet. On the other hand, a lot of technical issues have been already tackled and discussed. The only roadmap item is that after Push activities I'll do federated patches and merge requests. Idk yet what's next, I guess I should make a roadmap ^_^
bill-auger commented 1 year ago
Collaborator

fr33domlover -

i a bit confused at your interpretation of these docs - what do you mean by "keep track of them [details] and update stuff"

the entirety of forge-fed documentation is currently 4 paragraphs on the main repo README, and 4 paragraphs on the overview README plus some bullet-points - that is not very much detail - its about the bare minumum that accurately describes the project, its motivation, and goals

that aside, there is nothing in these docs for you to keep track of, and any changes to those docs would not require you to do anything - those docs are the public facing general introduction to the project - they are a reflection/description of what was and is happening, exactly what the OP is suggesting - if anything needs to be updated, it is only these two README files, and only as the spec matures, if that there is someday more to describe

fr33domlover - i a bit confused at your interpretation of these docs - what do you mean by "keep track of them [details] and update stuff" the entirety of forge-fed documentation is currently 4 paragraphs on the main repo README, and 4 paragraphs on the overview README plus some bullet-points - that is not very much detail - its about the bare minumum that accurately describes the project, its motivation, and goals that aside, there is nothing in these docs for you to keep track of, and any changes to those docs would not require you to do anything - those docs are the public facing general introduction to the project - they are a reflection/description of what was and is happening, exactly what the OP is suggesting - if anything needs to be updated, it is only these two README files, and only as the spec matures, if that there is someday more to describe
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.