Merge ipfs/ipfs, ipfs/community and ipfs/pm #191
Labels
need/community-input
Needs input from the wider community
Comments
|
This idea has grown on me. Consolidating those 3 repos into one ipfs/ipfs sounds like a good idea. Some things that reinforce the idea:
Also, looking at the list of repos, if we start using discourse we won't need to maintain ipfs/support or ipfs/faq. So after all the shuffling it might look like: ipfs/ipfs absorbs:
ipfs/websites absorbs:
discourse replaces:
code repositories:
other:
|
|
I agree very much, and I think we can also collapse repos like libp2p/community |
|
I still like this idea. |
|
People are leaning towards this, what are the next steps? |
daviddias
changed the title
|
Feedback from the rest of the team. |
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Idea
I think we should merge ipfs/ipfs, ipfs/community, and ipfs/pm into one repository.
Why
There is a lot of feedback going around, here and on IRC, that the GitHub organization is hard to navigate, and it is unclear where to ask questions, where to look for up-to-date information on the community, and where to find information about an implementation and to get a support. We are thinking through several solutions to this: overhauling our examples, or making better mans, or more realistically switching to Discourse or some other platform for having our discussions.
I think that this confusion comes from a different place: people aren't landing where we think they are landing.
Right now, we are supposed to have the following repo structure:
ipfs/ipfs links to everything. Unfortunately, very few people land there when looking to get involved more fully, and we have only very rarely utilized the issues on it. The content itself grows stale regularly. While it is useful as a document, it could be more useful as a landing pad if it was a living repository, with our community and project management happening there.
Realistically, what we have right now is a flat structure, and people don't necessarily see the useful guides to our repositories in ipfs/ipfs. Further, they may come to ipfs/community looking for that information; or they may be looking for ipfs/pm. Or they may be looking for ipfs/pm information in ipfs/go-ipfs or ipfs/js-ipfs.
I wonder if it might be better if we collapsed ipfs/ipfs, ipfs/community and ipfs/pm into one repository. This way, the project directory would be in the same place as the community and the project management. People would not need to go to multiple repositories to figure out the current state of IPFS or the IPFS community. If they wanted to look at a particular implementation, they can still go to go-ipfs or js-ipfs. But it would be very easy to see that the useful information is in ipfs/ipfs. If you wanted to propose a meetup, you'd go there. Or a new implementation. Or if you wanted to join our community calls.
I think that keeping ipfs/ipfs as a repo that didn't have community and pm resources on it made sense when people were able to easily see it and go to it, and when we were smaller. To date, it still has the most stars and watchers, so this may still be true. However, I think that these people have starred and watched it to keep updated on the state of IPFS - which is something we're not doing for them, right now.
Other possible collapses
I also think that ipfs/website, ipfs/examples, and ipfs/blog should be collapsed. They are all functionally the same to a naïve user. I think separating them out isn't helping us sandbox their usage.
The text was updated successfully, but these errors were encountered: