Defining our Github repos

[dylanPowers]

In order to help people find things we need to more narrowly define some of our repos. Some repos are very broad, overlap with others, or aren't defined at all. We also need to update the descriptions to reflect our definitions.
Some ideas:

• ipfs/infrastructure
  What I propose: Scripts and issues for any infrastructure that isn't a standalone repo
  Currently defined as: Infrastructure for IPFS users + devs
• ipfs/community
  As it stands this serves as infrastructure documentation and news for the ipfs community. We may
  want to split this up into a repo for infrastructure documentation and a repo for news. Since people
  are already subscribed to ipfs/ipfs we may want that to be our news channel. We could then
  rename this to ipfs/infrastructure-docs. I would even be a fan of removing this repo altogether and
  throwing it all into ipfs/infrastructure. For instance,
  https://github.com/ipfs/community/blob/master/dev/tools/hooks/commit-msg seems like it fits into
  the definition of ipfs/infrastructure
  Currently defined as: IPFS community
• ipfs/ipfs
  This repo has a large number of people "watching" it. That means they get notified on new issues.
  We need to use this to our advantage and not scare these people away. I believe the original
  purpose was to keep people notified of progress on ipfs. Using this as news would be good.
  Currently defined as: IPFS - The Permanent Web http://ipfs.io

[jbenet]

so far what i've been thinking:

• ipfs/infrastructure actual work done to improve the infrastructure (gateways, mailing lists, irc channel, etc) (e.g. document what it is, and file a bug here)
• ipfs/community an entry point + place for discussion for community members. documents all our practices, legal docs, who we are, and other random things. (e.g. swag, meetups, etc)
• ipfs/ipfs an entry point for the public at large, and something with low bandwidth periodic updates. major updates / requests.
• ipfs/papers academic style papers about ipfs
• ipfs/faq where anyone can ask general ipfs-protocol questions

the addition of ipfs/news could work-- are you thinking one issue per newsletter? we should still post it to ipfs-users

[dylanPowers]

Sorry @jbenet I pressed enter prematurely on that issue. I've modified the issue a bit more.
I'm using news in the sense of not necessarily a full blown newsletter, but notifying the community on anything they'd be potentially interested in. Things like ipfs/community#11 would fit.

[jbenet]

@dylanPowers when "Using this as news would be good." and "Things like ipfs/community#11 would fit." i disagree. we should not spam all of those people random little things like our swag.

Let's think about it this way-- there's concentric circles of involvement, with different "home" repos:

• the core ipfs dev team (building daily) ipfs/community
• the broader ipfs community (actively participating on github, irc, etc) ipfs/community
• the broader set of people interested (mostly watching, rarely participating) ipfs/ipfs
• the public at large (not watching, but may notice things on twitter/HN/etc) ipfs/ipfs

The first two groups care about more messages than the latter groups. I also want to distinguish "community" (and use the word community because it is very clear) to be a place where we discuss various random things. And "infrastructure" is more about "working on" the tools and systems we use to work together.

[dylanPowers]

Okay, I think I'm starting to get a better picture of your thinking. Putting it like that helped a lot.

---

I'm trying to further understand what you mean by

"infrastructure" is more about "working on" the tools and systems we use to work together.

specifically the "working on" part. Is this opposed to the documentation of how to use "tools and systems"? I'm confused on that point because previously you stated "document what it is" as an example

ipfs/infrastructure actual work done to improve the infrastructure (gateways, mailing lists, irc channel, etc) (e.g. document what it is, and file a bug here)

Also confusingly for me you stated that community "documents all our practices"

ipfs/community ... documents all our practices, legal docs, who we are, and other random things. (e.g. swag, meetups, etc)

and I see documenting practices and how we use the tools as one in the same because the practices and tools are dependent upon each other.

Expanding upon this would help me out.

---

Sorry to nitpick, I just want to be crystal clear in my understanding.

[jbenet]

he "working on" part

what i mean is that infrastructure is the repo we post things like "bug in gateway", or "need to add an irc bot". it should also document (i.e. list) the actual infrastructure we use.

for example, this list belongs in infrastructure not community:

IPFS infrastructure consists of:

Computing:
- Gateway nodes
- Bootstrap nodes
- CI servers (jenkins, travis, etc)

Communications:
- Github repos
- IRC Channel
- Mailing Lists

only the "communications" part would need to be described in community (and yes, there may be redundancy of information there) but everything else (and certainly all actual work we have to do to improve any of these ) would be in infrastructure.

• infrastructure - dry, work repo. (the things, fixing the things)
• community - fuzzy, social repo. (practices using the things)

[dylanPowers]

I think I got it now. I'm going to test myself real quick and tell me if I'm wrong:

• Document waffle.io/ipfs/ipfs #8 - Should be in community because it's about using waffle.
• Move jbenet/node-ipfs to ipfs/node-ipfs ipfs#61 and Org logo could be prettier ipfs#62 - Should be here in infrastructure because they deal with an issue with a tool (the Github organization).
• https://github.com/ipfs/community/tree/master/dev/tools - Should also be moved to infrastructure since it's a tool

One line summaries:

• Infrastructure: Tools and systems for the community
• Community: General discussion and documentation on community practices

If you agree with these I'll set them as the Github repo summary for the respective repo.

[jbenet]

#8 - Should be in community because it's about using waffle.

sure, though could also go in infra. this is in the small intersection of the two. (it's ok to have some overlap-- human, organic definitions tend to)

ipfs/ipfs#61 and ipfs/ipfs#62 - Should be here in infrastructure because they deal with an issue with a tool (the Github organization).

Yep! 👍

https://github.com/ipfs/community/tree/master/dev/tools - Should also be moved to infrastructure since it's a tool

Yes, and no. this is also in the intersection -- because it's a set of tools that ipfs community members should be aware of and use. Most people will not have to look at infrastructure ever, most people developing/participating will have to look at community. In this case, i'd prefer the hooks remaining there for that reason, but if they're linked from there, it doesn't matter much. ((If all the repos were rooms in a (big) house, community is the living room. infrastructure is the garage/workshop.))

For the one-line summaries, sure.