Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Hart Montgomery <hmontgomery@...>

Hi Arun,

Thanks for bringing this up to everyone.  I think #1, in particular, is a big issue.  Most projects have their own specific PR requirements that can be difficult to get right on the first time.  Maintainers also tend to respond to and deal with PRs from people that they know more quickly, and PRs from unknown contributors that are useful but maybe do a couple of things wrong because the contributors are new can get "black holed."  I guess this plays into #3 as well.

Two things that I've recommended for these problems in some of the projects I've worked on are as follows:
  1. Require that maintainers address PRs in order (except for some critical fixes).  This means that people cannot just skip PRs for people that they don't know, and must respond to all PRs in a timely manner.  
  2. Never close someone's PR without explaining why.  Even if it's a totally foolish PR, at least a sentence or two is required.
I think these rules help reduce discouragement for new people trying PRs.  I don't think we want to regulate things at a Hyperledger level, but I did want to share things that seem to work for projects that I work on/follow closely.

Thanks a lot for your time, and have a great day.


From: tsc@... <tsc@...> on behalf of Arun S M <arun.s.m.cse@...>
Sent: Saturday, February 6, 2021 5:20 AM
To: David Boswell <dboswell@...>
Cc: Tracy Kuhrt <tracy.a.kuhrt@...>; tsc@... <tsc@...>; SIG-Chairs@... <SIG-Chairs@...>
Subject: Re: [Hyperledger TSC] [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors
Adding onto this discussion,

The entry barriers that I have found while asking the developer community to get involved are
1. First time contributors think that they need to spend a significant amount of time before making attempts to contribute. They are unsure of their code acceptance by a project.
2. Lack of awareness on available opportunities to get involved.
3. Number of reworks on a PR. due to lack of information on better practices followed at Hyperledger.

Building upon the idea of aggregating contribution opportunities at one place, and similar discussions I have had with another project in Hyperledger.
How about also categorizing those opportunities into different verticals?
- Documentation efforts for those who wish to help out there.
- Porting efforts, if somebody is new to a programming language or doesn't know about a project. Here are low hanging fruits/easy picks.
- Adding to the test coverage, implementing fully designed modules. For a slightly mature developer.
- A section for specific requirements. For example, call out need for help on expertise from verifiable credentials use cases, call out need to work on a setting up a test network, call out need to work on a backend. This way specific people interested in a domain can even subscribe to available opportunities.
- Influencing the roadmap of a project. This is where the passionate developers/organizations join by themselves.

Weekly dev letters can be used to publish a link to this page. Also, highlight new opportunities added upon here.


On Sat, Feb 6, 2021 at 4:19 AM David Boswell <dboswell@...> wrote:

Out of all of the ideas that came out of that discussion, I think this one about rolling up contribution opportunities could bring the most benefit to the entire community.

Right now a potential contributor needs to look at 72 different places (16 projects, 42 labs repositories, 5 Working Groups, 9 Special Interest Groups) to get a full picture of what they can contribute to.  Having one place that aggregates everything that they could contribute to would be a much lower barrier to entry.

And bringing all contribution opportunities together in one place could promote collaboration among different parts of the community.  It seems entirely possible that different groups are working separately on similar tasks without realizing it because there isn't a lot of visibility across the whole of the community.  Could we get a better sense of where to combine efforts if we did roll opportunities up?

It seems like it should be possible to have one page on the wiki that aggregates all 'help wanted' and/or all 'good first issues'.  Last year Ry installed a Confluence plug-in that let us embed Github issues onto a wiki page (see example at link below) and that could be the basis of something that pulled from a wider collection of sources.


On Thu, Feb 4, 2021 at 2:02 PM Kuhrt, Tracy A. via <> wrote:

On January 11th, I provided a report back on the SIG chair meeting that I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.


This is the email to discuss item #5 Technical contributors -- can the TSC help recruit people to work on things that the SIGs are doing, such as a Labs project.  Can we roll up contribution opportunities across SIGs into one place?


Here is what has been mentioned on the previous thread so far regarding this topic:


From Arun:

Streamlining the process would help. For example, in few of the labs projects asking for a new feature or raising a defect is as simple as adding a new issue on GitHub. TSC can review the current process followed by the SIGs, check if they all are using similar ways of communication, requesting for comments, how are the community call times are allotted to different topics. TSC can play the role of being a steward to help SIGs with technical contributions if TSC is aware of what's going on.



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at

Join to automatically receive all group messages.