Js-ipfs: RFC: Make it easier to contribute to js-ipfs

[dirkmc]

Currently it's quite complicated to contribute to js-ipfs because

1. It's a large project with many moving parts
2. Tests take a long time to run
3. Most changes to js-ipfs require changes to dependent repos, eg interface-js-ipfs-core

I'm opening this issue as an RFC for ways to make it easier to contribute, please add your suggestions below.

[dirkmc]

I suggest we

• refactor README.MD into smaller pieces
• update CONTRIBUTING.MD to add more information about how pieces of the project are related to each other (eg interface-js-ipfs-core)

[dirkmc]

I suggest we add a way to run specific sets of tests with a glob, eg just the http interface refs* tests

[kav]

Related proposal: https://github.com/ipfs/team-mgmt/issues/834

[kav]

Also, as a user who is not a contributor but has looked at contributing I'd propose there is another issue.

1. Issues are often sufficiently clear to current contributors but not clear at all to new contributors. (e.g. https://github.com/ipfs/js-ipfs-http-client/issues/142)

[hugomrdias]

I suggest we add a way to run specific sets of tests with a glob, eg just the http interface refs* tests

you can do npx aegir test -t node --grep <pattern> to filter tests

[dirkmc]

Good tip @hugomrdias 👍 We should add that to the contributing guidelines

[dirkmc]

@kav that's a good point. I like the way that the go-filecoin project structure their issues, so that a new contributor not only has a lot of context but also is given an idea of where in the code to start, eg see https://github.com/filecoin-project/go-filecoin/issues/2729

[Prabhakar-Poudel]

One Elephant in the room I would say is a lot of open issues that I have come across, and spend some time debugging it turns out to be "not an issue anymore".
We need to check all existing issues and prune the ones that are fixed already.

[Prabhakar-Poudel]

Another thing that could be improved is labeling the issues. "Help wanted" with "Difficulty: easy" sounds pretty much like "Good first issue", but my experience was it was not super easy even though it was marked so. The reason could be when we mark this issue we think it is easy because we have all the context of the issue whereas a beginner picking it up may have to spend hours to get around it.
One way to improve this would be to mark the code points to look up to fix the issue, and a couple of pointers (doc, go implementation, etc) to go through before picking it up. This we should do for all "Difficulty: easy" issues.

[dirkmc]

Thanks @Prabhakar-Poudel that's good feedback. If you find an issue that you would be interested in taking on, but would like some context, please feel free to ask on that issue so you don't have to spend hours digging through the code

[Prabhakar-Poudel]

@dirkmc
Also wondering why there are issues marked as "Priority: High" and open since 2016. This I have seen across repositories in ipfs domain.
If it is marked high priority and not fixed for long (> 3 mo), I think we need to move it to low priority and add more information so that it becomes easy to pick them up.