Hi Mike,
On Fri, 20 Sep 2019, Mike Hommey wrote:
> On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:
> > During the Virtual Git Contributors' Summit, Dscho brought up the topic of
> > "Inclusion & Diversity". We discussed ideas for how to make the community
> > more welcoming to new contributors of all kinds. Let's discuss some of
> > the ideas we talked about, and some that have been growing since.
> >
> > Feel free to pick apart all of the claims I make below. This is based
> > on my own experience and opinions. It should be a good baseline
> > for us to all arrive with valuable action items.
> >
> > I have CC'd some of the people who were part of that discussion. Sorry
> > if I accidentally left someone out.
> >
> > I. Goals and Perceived Problems
> >
> > As a community, our number one goal is for Git to continue to be the best
> > distributed version control system. At minimum, it should continue to be
> > the most widely-used DVCS. Towards that goal, we need to make sure Git is
> > the best solution for every kind of developer in every industry. The
> > community cannot do this without including developers of all kinds. This
> > means having a diverse community, for all senses of the word: Diverse in
> > physical location, gender, professional status, age, and others.
> >
> > In addition, the community must continue to grow, but members leave the
> > community on a regular basis for multiple reasons. New contributors must
> > join and mature within the community or the community will dwindle. Without
> > dedicating effort and attention to this, natural forces may result in the
> > community being represented only by contributors working at large tech
> > companies focused on the engineering systems of very large groups.
> >
> > It is worth noting that this community growth must never be at the cost
> > of code quality. We must continue to hold all contributors to a high
> > standard so Git stays a stable product.
> >
> > Here are some problems that may exist within the Git community and may
> > form a barrier to new contributors entering:
> >
> > 1. Discovering how to contribute to Git is non-obvious.
> >
> > 2. Submitting to a mailing list is a new experience for most developers.
> > This includes the full review and discussion process.
> >
> > 3. The high standards for patch quality are intimidating to new
> > contributors.
> >
> > 4. Some people do not feel comfortable engaging in a community without
> > a clear Code of Conduct. This discomfort is significant and based on real
> > experiences throughout society.
> >
> > 5. Since Git development happens in a different place than where users
> > acquire the end product, some are not aware that they can contribute.
>
> 6. Newcomers don't really have any idea /what/ they could contribute.
> They either have to come with their own itch to scratch, or read the
> code to figure out if there's something to fix.
I think this is very related to the "not only open the door, but invite
contributors in" idea mentioned upthread.
Speaking from my experience as mentor in particular in Outreachy, it is
often not obvious to old-timers in this here project (including myself!)
how intimidating even the idea of "scratching your own itch" is, and
it can be tremendously helpful to even so much as seeing the problem
stated by somebody else first ("Others agree with me! I need not have
doubted myself when I ran into this problem, it really is a bug that
needs to be fixed!").
Additionally, it is no longer all that easy to come up with an "own
itch" to scratch, as the most common workflows work reasonably well in
Git. Yet, it seems that some users _still_ want to "give back" by
contributing patches. Or they just want to see their name in the next
version's announcement mail.
To address both concerns, I started this little experiment a while ago
(but announced it only during a Git IRC standup):
https://github.com/gitgitgadget/git/issues is open, intended to
accumulate possible project ideas. It seems to work reasonably well,
there already have been volunteers who picked up on some of those ideas
I (and Denton) listed.
Hopefully this issue tracker (together with https://crbug.com/git which
targets users more comfortable with that flavor of issue trackers) will
help address your bullet point?
Ciao,
Dscho
