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

Re: [TOPIC 07/11] New Contributors and Discord

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 22, 2024, 19:15 UTC
Message-ID
<xmqqsetr5wl1.fsf@gitster.g>
In-Reply-To
<Zu78E+0Uk5fMSeQv@five231003>
Kousik Sanagavarapu <five231003@gmail.com> writes:
> Another thing that would be great is having a list of things on which a
> new contributor could work on.  GitGitGadget's issues used to do this by
> tagging the appropriate issues "good-first-issue" but I guess it is not
> properly maintained anymore.
True.
> I know there is also searching for "#leftoverbits" or "low hanging fruit"
> on the list but the "good-first-issue" tagged issues on GitGitGadget are
> probably more new-contributor-friendly than whole email threads.

Yes, even with these search terms, finding an issue to work on from the mailing list archive would not be suited for an absolute newbie for four reasons.

 * Anybody can write "low hanging fruit" in their message.  Such a
   label added by somebody without understanding the issue would
   lead readers in a wrong direction.  These phrases need to be
   reserved for a case where the person who adds _know_ they can
   solve it themselves fairly easily if they dedicated time on it
   for a few days but deliberately chooses to leave it on the table
   unsolved.
 * "#leftoverbits" is just that---a direction we could explore in
   the future, and the journey that goes in the direction is limited
   to a short and trivial one.
 * Both labels are opinions of the author at the time of writing.
   It may turn out that what was thought of as a "low hanging fruit"
   is not all that easy, and it may turn out that what was labeled
   with "#leftoverbits" would not lead to a productive direction
   after somebody actually tries.
 * And the list archive by its nature will show hits for ideas
   marked with "#leftoverbits" and/or "low hanging fruit" that have
   already been fully explored, and those who completed the task may
   not reference to the original message that inspired them in the
   References: header, so the archive search cannot show that the
   task is completed already.

We could improve the situation for all of the above four downsides by making it a collective habit to follow-up these messages with "#leftoverbits" or "low hanging fruit" in it, if the situation changes, but your "whole email threads" comment still applies.

Unless we make a habit of sending a separate message with such markings in which we summarize the discussion, that is.

#leftoverbit. Perhaps one of the how-to documents that describe the project workflow (i.e. my first contribution, how to review patches, etc.) can mention the best-current-practice to encourage such use of these tags? Something like

 - When you mention a good idea that is not squarely inside the
   theme of the current discussion, instead of adding "#leftoverbit"
   mark in the message, write a separate message as a follow-up to
   the message and summarize the issues and idea in such a way that
   people who later looks for a message with such a mark can grok
   the idea by the message alone, while still allowing them to learn
   more about the backstory by going back in the discussion thread.
 - After you find "#leftoverbit" message and worked on it (either
   you produced a patch series, or you failed and know why the idea
   described in the #leftoverbit message does not work), make sure
   you mention the original "#leftoverbit" message's message-id in
   such a way that a person who found the "#leftoverbit" message can
   find your message.  Sending your patch series as a reply to such
   a message would be the easiest way to achieve it.
or somesuch, perhaps.
> Not exactly a regular community meeting but Review Club was kind of a
> large step towards this I guess.  I was exactly in one review club
> meeting and it sadly got shutdown right after that :').

Anybody motivated enough can take initiative to reignite the Review Club; you do not need permissions from past hosts to do so.

Quite honestly, I sometimes failed to find much value in the review these meetings produced, and I suspect it was not due to lack of preparation on participants' side, but was largely due to the fact that the face-to-face meetings cannot go to sufficient depth in technical conversion in a single sitting.

It might have been more productive format if it weren't "let's critique this series on the fly". For example, it could instead have been "There is an excellent reviewer-contributor exchange thread on the list. Let's read these exchanges together and learn how to effectively convey the idea from the original author's side, and idea for improvements from the reviewer's side". I dunno.

There however was a lot of value in the mere fact that people had a face-to-face discussion on something, anything, that was related to the project.

Thanks.
Previous: Kousik SanagavarapuNext: Junio C Hamano
Message 20 of 38 in “Notes from the Git Contributor's Summit, 2024”
  1. Taylor BlauSep 20, 2024
  2. 01/11 RustTaylor Blau, Sep 20, 2024
  3. rsbecker@nexbridge.comSep 20, 2024
  4. Sean AllredSep 23, 2024
  5. rsbecker@nexbridge.comSep 23, 2024
  6. Phillip WoodSep 24, 2024
  7. rsbecker@nexbridge.comSep 24, 2024
  8. Sean AllredSep 27, 2024
  9. rsbecker@nexbridge.comSep 27, 2024
  10. rsbecker@nexbridge.comSep 27, 2024
  11. 02/11 Top-level lib/ directoryTaylor Blau, Sep 20, 2024
  12. 03/11 Structured Error HandlingTaylor Blau, Sep 20, 2024
  13. 04/11 Platform Support PolicyTaylor Blau, Sep 20, 2024
  14. 05/11 : SHA 256 / Git 3.0Taylor Blau, Sep 20, 2024
  15. Junio C HamanoSep 20, 2024
  16. 06/11 Git and Software Freedom ConservancyTaylor Blau, Sep 20, 2024
  17. 07/11 New Contributors and DiscordTaylor Blau, Sep 20, 2024
  18. Junio C HamanoSep 20, 2024
  19. Kousik SanagavarapuSep 21, 2024
  20. Junio C HamanoSep 22, 2024
  21. Junio C HamanoSep 22, 2024
  22. Konstantin RyabitsevSep 23, 2024
  23. Junio C HamanoSep 23, 2024
  24. Konstantin RyabitsevSep 24, 2024
  25. Junio C HamanoSep 24, 2024
  26. Konstantin RyabitsevSep 24, 2024
  27. Phillip WoodSep 27, 2024
  28. Junio C HamanoSep 27, 2024
  29. Phillip WoodOct 1, 2024
  30. 08/11 Modern Build SystemsTaylor Blau, Sep 20, 2024
  31. Eli SchwartzSep 23, 2024
  32. Patrick SteinhardtSep 24, 2024
  33. 09/11 Bundle-URI on fetch / resume-able cloneTaylor Blau, Sep 20, 2024
  34. 10/11 Project TrackingTaylor Blau, Sep 20, 2024
  35. Junio C HamanoSep 20, 2024
  36. Junio C HamanoSep 20, 2024
  37. Phillip WoodSep 23, 2024
  38. 11/11 git-scm.com state of the siteTaylor Blau, Sep 20, 2024

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.