git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [DISCUSSION] Growing the Git community

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 20, 2019, 17:43 UTC
Message-ID
<xmqqsgoqvp6s.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com>
Derrick Stolee <stolee@gmail.com> writes:
Show 6 quoted lines
> 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.

I have quite a lot of problem with this attitude to place the world domination as the ultimate goal, even though it may call for the need for sub-goals, one of which is this one,

> 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.

that I can 100% agree with. Also I agree that the tactical moves listed like improved onboading and documentation (omitted from this response) are all good.

> After we put items 1-4 in place, we should reach out to the
> general tech community that we are interested in new
> contributors. It's not enough to open the door, we should
> point people to it.
I am also somewhat negative on this.

I want to see our system to support the use cases of its users well, which would lead to its users being happy to use the system.

I think that (and in the remainder, I won't write "I think that" for brevity) it should be the primary goal. By being a system that is useful and pleasant to use, we may gain more users, and we may gain users from many more different fields and industries and make these new users happy. But it should merely be a result, consequence of being a good system for its users, and not a goal of its own, to acquire new users from new industries.

And by being a project that works on such a good system for its users, with welcoming atmosphere to those who are prepared to reciprocate the same respect while interacting with us, the community may attract more new members, developers, advocates, tech writers, etc. It should merely be a result, consequence of being a good community for its members, and not a goal on its own, to acquire new community members.

We first should make sure that we serve existing users and existing community members well. So well that other people who are not yet our "existing" users and members would want to become part of us, in order to join the fun and share the benefit. If we cannot serve even the existing members well, we shouldn't be talking about acquiring new members.

Growth and the world domination may come as a consequence, and I would not reject it when it happens, but we should not be actively seeking it.

It follows that "in this quarter, we acquired these high profile projects as users", "we have this many new contributors this month", "the acceptance rate of the patches from contributors with less than 3 months experience dipped by 20% this month" etc. are not best measures of success. What's preferable would be yardsticks to gauge the community-member happiness (e.g. "This many percent of total community member population have been active this month").

Thanks.
Previous: Garima SinghNext: Junio C Hamano
Message 42 of 45 in “[DISCUSSION] Growing the Git community”
  1. Derrick StoleeSep 19, 2019
  2. Denton LiuSep 19, 2019
  3. Emily ShafferSep 19, 2019
  4. Jeff KingSep 19, 2019
  5. Junio C HamanoSep 20, 2019
  6. Garima SinghSep 20, 2019
  7. Junio C HamanoSep 20, 2019
  8. Klaus SembritzkiSep 19, 2019
  9. Klaus SembritzkiSep 19, 2019
  10. Klaus SembritzkiSep 19, 2019
  11. Klaus SembritzkiSep 20, 2019
  12. Klaus SembritzkiSep 20, 2019
  13. Klaus SembritzkiSep 20, 2019
  14. Klaus SembritzkiSep 20, 2019
  15. Klaus SembritzkiSep 20, 2019
  16. Mike HommeySep 19, 2019
  17. Johannes SchindelinSep 23, 2019
  18. Jakub NarebskiOct 1, 2019
  19. Jeff KingSep 19, 2019
  20. Derrick StoleeSep 20, 2019
  21. Jeff KingSep 20, 2019
  22. Elijah NewrenSep 19, 2019
  23. Pierre TardySep 25, 2019
  24. Derrick StoleeSep 25, 2019
  25. Jakub NarebskiOct 4, 2019
  26. Philip OakleySep 25, 2019
  27. Jakub NarebskiOct 4, 2019
  28. Emily ShafferNov 12, 2019
  29. Johannes SchindelinNov 12, 2019
  30. Christian CouderNov 13, 2019
  31. Thomas GummererNov 13, 2019
  32. Emily ShafferNov 14, 2019
  33. Jeff KingNov 14, 2019
  34. Junio C HamanoNov 15, 2019
  35. Pratyush YadavNov 14, 2019
  36. Thomas GummererNov 14, 2019
  37. Philip OakleySep 20, 2019
  38. brian m. carlsonSep 20, 2019
  39. Randall S. BeckerSep 20, 2019
  40. Jakub NarebskiOct 4, 2019
  41. Garima SinghSep 20, 2019
  42. Junio C HamanoSep 20, 2019
  43. Junio C HamanoSep 20, 2019
  44. Derrick StoleeSep 23, 2019
  45. Johannes SchindelinSep 23, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.