New Contributor Pain Points

[mikeal]

Let's use this thread to document any friction points in the contribution experience to IPFS. The Community WG will end up using this list as the basis for a more detailed plan to improve the experience of contributing to IPFS as well as new resources that can be created to support "First Commit" events in the future.

[pkafei]

Hosting an IPFS contributor event which will give us some insight on exactly what are some of these pain points. https://github.com/protocol/event-management/issues/132

[daviddias]

3 great sources to help identify pain points are:

• Our own discuss where users post questions all the time -- https://discuss.ipfs.io/c/coding
• Stackoverflow IPFS label -- https://stackoverflow.com/questions/tagged/ipfs
• Ethereum Stack Exchange that gets a lot of IPFS questions as well -- https://ethereum.stackexchange.com/questions/tagged/ipfs

[pkafei]

@daviddias Thanks for the links. I find the Stackoverflow and Ethereum Stack Exchange questions especially useful.

[daviddias]

You bet :)

Remembered another source. The IPFS Users Mailing List - https://groups.google.com/forum/#!forum/ipfs-users

[momack2]

I've been leveling-up on other OSS community best practices that we should learn from. Some thoughts from the early days:

• a bot to thank new contributors for their first issue/PR, auto assign a reviewer, and give the reporter a sense of ETA on when they'll hear back / next steps
• metrics on turn around time for new contributor issues/PRs (goal to have first review within 48 hrs)
• highlighted/profiled issues for new contributors within github (w/ explanations for what they unlock for the future impact of the project) - and a way to connect people back to this stack after they make their first contribution
• a re-engagement point (email, github bot, etc) ~48hr after first engagement

Something we could do a better job of is visualizing to new contributors how their work can impact the future of the project and where the project is heading (such that they can contribute in ways that align with that vision, or fork and go their own direction).

[pkafei]

@momack2

a bot to thank new contributors for their first issue/PR, auto assign a reviewer, and give the reporter > a sense of ETA on when they'll hear back / next steps

We can use Protobots to deal with the above tasks.

metrics on turn around time for new contributor issues/PRs (goal to have first review within 48 hrs)

Is this something that can be accomplished in a bug tracker, if not we should consider building this widget.

highlighted/profiled issues for new contributors within github (w/ explanations for what they unlock for the future impact of the project) - and a way to connect people back to this stack after they make their first contribution

I really like this idea, perhaps we can add the highlighted issue in Awesome IPFS. We can even make a Contributor of the Week section in the newsletter and I give a special shoutout to interesting contributions during the IPFS Weekly Call.

a re-engagement point (email, github bot, etc) ~48hr after first engagement

The first thing that comes to mind is creating a Protobot that thanks contributors and gives them a list of issues similar to the one that they just completed. For example, if a user just finished working on an issue labeled Is API in go-ipfs, we can give them a list of other tickets labeled Is API and go-ipfs.

[mikeal]

metrics on turn around time for new contributor issues/PRs (goal to have first review within 48 hrs)

Is this something that can be accomplished in a bug tracker, if not we should consider building this widget.

We can get this data out of the gharchive API with decent accuracy (we'll probably want to set of a window of 1 year back to check if they've contributed before).

[mikeal]

@ipfs/working-group-captains would love to get thoughts from the working groups on this.

[lidel]

I agree with points from https://github.com/ipfs/community/issues/369#issuecomment-446032901 about labeling "good first issues" and being responsive, those are low hanging fruits.

We should find a way to prioritize reviews from first time contributors and make sure they get some feedback on PR in 48h, even if it is "we are a bit swamped right now, but we really appreciate your PR and will do our best to review it by the end of next week". Small things like this make a big difference.

ps. @pkafei's comment reminded me that back in the day (~2015) Weekly newsletter had a list of github handles of people who contributed to IPFS in some way. I miss that! In case that does not scale anymore (too many nicknames across all repos) we could just list First Time Contributors.

ps2. Are we planning to run something like GSoC at some point? It creates a time-bound working relationship and an opportunity for a honest retrospective, eg. gathering feedback about pain points contributor experienced. (PL folks can read a good discussion about GSoC in this private Slack thread)

[alanshaw]

Weekly newsletter had a list of github handles of people who contributed to IPFS in some way

@lidel JS IPFS releases now have that!

We're using name-your-contributors and this script to get an output like:

See https://github.com/ipfs/js-ipfs/issues/1721 for full list.

[mikeal]

@alanshaw this is really cool, it even calls out non-code contributions!