From: Junio C Hamano <gitster@pobox.com>
To: Kousik Sanagavarapu <five231003@gmail.com>
Cc: Taylor Blau <me@ttaylorr.com>, git@vger.kernel.org
Subject: Re: [TOPIC 07/11] New Contributors and Discord
Date: Sun, 22 Sep 2024 12:15:22 -0700 [thread overview]
Message-ID: <xmqqsetr5wl1.fsf@gitster.g> (raw)
In-Reply-To: <Zu78E+0Uk5fMSeQv@five231003> (Kousik Sanagavarapu's message of "Sat, 21 Sep 2024 22:32:11 +0530")
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.
next prev parent reply other threads:[~2024-09-22 19:15 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-20 14:15 Notes from the Git Contributor's Summit, 2024 Taylor Blau
2024-09-20 14:17 ` [TOPIC 01/11] Rust Taylor Blau
2024-09-20 16:20 ` rsbecker
2024-09-23 2:25 ` Sean Allred
2024-09-23 12:17 ` rsbecker
2024-09-24 15:30 ` Phillip Wood
2024-09-24 22:44 ` rsbecker
2024-09-27 9:37 ` Sean Allred
2024-09-27 12:23 ` rsbecker
2024-09-27 17:40 ` rsbecker
2024-09-20 14:17 ` [TOPIC 02/11] Top-level lib/ directory Taylor Blau
2024-09-20 14:18 ` [TOPIC 03/11] Structured Error Handling Taylor Blau
2024-09-20 14:19 ` [TOPIC 04/11] Platform Support Policy Taylor Blau
2024-09-20 14:19 ` [TOPIC 05/11]: SHA 256 / Git 3.0 Taylor Blau
2024-09-20 19:22 ` Junio C Hamano
2024-09-20 14:20 ` [TOPIC 06/11] Git and Software Freedom Conservancy Taylor Blau
2024-09-20 14:20 ` [TOPIC 07/11] New Contributors and Discord Taylor Blau
2024-09-20 22:48 ` Junio C Hamano
2024-09-21 17:02 ` Kousik Sanagavarapu
2024-09-22 19:15 ` Junio C Hamano [this message]
2024-09-22 19:44 ` Junio C Hamano
2024-09-23 13:51 ` Konstantin Ryabitsev
2024-09-23 21:31 ` Junio C Hamano
2024-09-24 18:06 ` Konstantin Ryabitsev
2024-09-24 19:15 ` Junio C Hamano
2024-09-24 19:23 ` Konstantin Ryabitsev
2024-09-27 10:08 ` Phillip Wood
2024-09-27 19:22 ` Junio C Hamano
2024-10-01 15:23 ` Phillip Wood
2024-09-20 14:21 ` [TOPIC 08/11] Modern Build Systems Taylor Blau
2024-09-23 2:01 ` Eli Schwartz
2024-09-24 12:13 ` Patrick Steinhardt
2024-09-20 14:22 ` [TOPIC 09/11] Bundle-URI on fetch / resume-able clone Taylor Blau
2024-09-20 14:22 ` [TOPIC 10/11] Project Tracking Taylor Blau
2024-09-20 19:41 ` Junio C Hamano
2024-09-20 19:49 ` Junio C Hamano
2024-09-23 9:15 ` Phillip Wood
2024-09-20 14:23 ` [TOPIC 11/11] git-scm.com state of the site Taylor Blau
-- strict thread matches above, loose matches on Subject: below --
2024-08-24 17:20 [GSoC][PATCH] unit-tests: add tests for oidset.h Ghanshyam Thakkar
2024-08-26 7:02 ` Patrick Steinhardt
2024-08-26 9:31 ` Christian Couder
2024-08-26 15:46 ` Junio C Hamano
2024-09-26 18:28 ` Junio C Hamano
2024-09-26 19:12 ` [PATCH] howto-maintain-git: discarding inactive topics Junio C Hamano
2024-09-27 8:57 ` [GSoC][PATCH] unit-tests: add tests for oidset.h Christian Couder
2024-09-27 18:47 ` Junio C Hamano
2024-09-28 7:02 ` Patrick Steinhardt
2024-09-30 18:48 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqsetr5wl1.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=five231003@gmail.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).