You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
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.
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).
I agree with points from #369 (comment) 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)
Activity
pkafei commentedon Nov 30, 2018
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 commentedon Dec 9, 2018
3 great sources to help identify pain points are:
pkafei commentedon Dec 10, 2018
@daviddias Thanks for the links. I find the Stackoverflow and Ethereum Stack Exchange questions especially useful.
daviddias commentedon Dec 10, 2018
You bet :)
Remembered another source. The IPFS Users Mailing List - https://groups.google.com/forum/#!forum/ipfs-users
momack2 commentedon Dec 11, 2018
I've been leveling-up on other OSS community best practices that we should learn from. Some thoughts from the early days:
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 commentedon Dec 11, 2018
@momack2
We can use Protobots to deal with the above tasks.
Is this something that can be accomplished in a bug tracker, if not we should consider building this widget.
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.
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 APIingo-ipfs, we can give them a list of other tickets labeledIs APIandgo-ipfs.mikeal commentedon Dec 11, 2018
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 commentedon Dec 19, 2018
@ipfs/working-group-captains would love to get thoughts from the working groups on this.
lidel commentedon Dec 19, 2018
I agree with points from #369 (comment) 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 commentedon Jan 3, 2019
@lidel JS IPFS releases now have that!
We're using
name-your-contributorsand this script to get an output like:See ipfs/js-ipfs#1721 for full list.
mikeal commentedon Jan 3, 2019
@alanshaw this is really cool, it even calls out non-code contributions!