From: Junio C Hamano <gitster@pobox.com>
To: Naomi Ibe <naomi.ibeh69@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [OUTREACHY] Permission To Work On Tasks
Date: Fri, 06 Oct 2023 16:28:52 -0700 [thread overview]
Message-ID: <xmqqr0m75o0b.fsf@gitster.g> (raw)
In-Reply-To: <CACS=G2zsJxP+NWuosZyrFGctJptHNYTrULErRo_Ns41KeMuMqA@mail.gmail.com> (Naomi Ibe's message of "Fri, 6 Oct 2023 23:41:35 +0100")
Naomi Ibe <naomi.ibeh69@gmail.com> writes:
> First issue is here https://github.com/gitgitgadget/git/issues/635 ,
> involving changing the "die()" error msg outputs to all lowercase. I
> found a few files here https://github.com/git/git/tree/master/builtin
> where the "die()" error msg had some uppercase in them (add.c in lines
> 185, 203, 205, 211 and 571) (branch.c in lines 521, 525, 581, 597,
> 599, 627, 629, 643, 650, 652, 776, 926, 954 and 968). If I'm allowed
> to work on this issue, how many files should I edit? The last closed
> issues related to this issue had edited five files.
As the "general microproject information" page says, it is a good
idea to do just one quality-focused microproject per applicant.
If I were on the receiving end to review such a patch, I would
probably find it is too boring a burden if it had several unrelated
commands covered by a single patch, and would stop reading in the
middle.
If I were on the sending end to work on them for real (not as "dip
my toe in the water and say hello to the more experienced
developers" exercise), I would probably prepare a series of patches,
one for each git subcommand (e.g. "add", "branch", "log", etc.), and
for shared infrastructure files, one for each subsystem that they
are part of (this is harder to do for a new person who do not know
what subsystems exist, and which files implement which subsystem),
but for a microproject, I would say a single file under builtin/*
hierarchy would be a good size.
> Second issue is this https://github.com/gitgitgadget/git/issues/302 .
> Is it still available to be worked on? I notice it was opened in 2019
Stepping back a bit, do you agree with what the issue says?
Remember, these "issue"s are merely one person's opinion and not
endorsed by the community.
Before you ask "is it still available", do you know the current
status (not the status of the "issue")? Have you looked at "git
commit --help" to find it out yourself to see if "now" is singled
out? Here is what we say in our documentation:
In addition to recognizing all date formats above, the --date
option will also try to make sense of other, more human-centric
date formats, such as relative dates like "yesterday" or "last
Friday at noon".
So apparently it is still "available". It is a different matter how
well a patch that adds "now" to the examples listed there will be
accepted, though. During a microproject, one of the things new
contributors are expected to learn is to convince others the cause
of their patches with the proposed commit log message well.
Finally, you do not need to obtain permission to work on anything
around here. You work on what interests you, send the result (or
send request for help, to which others may offer advices if the
problem you are solving looks interesting) to be reviewed, and will
be thanked for working on it when your patch is applied. To avoid
duplicated work, you might want to say "I'm interested in doing
this, but is anybody already doing it? If so I'll avoid stepping on
their toes", but otherwise, you are expected to go wild on your own
;-)
Have fun.
next prev parent reply other threads:[~2023-10-06 23:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-06 22:41 [OUTREACHY] Permission To Work On Tasks Naomi Ibe
2023-10-06 23:28 ` Junio C Hamano [this message]
2023-10-07 7:20 ` Christian Couder
2023-10-09 13:45 ` Christian Couder
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=xmqqr0m75o0b.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=naomi.ibeh69@gmail.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 read-only IMAP folder(s) and NNTP newsgroup(s).