Re: [OUTREACHY] Permission To Work On Tasks

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 6, 2023, 23:28 UTC
Message-ID: <xmqqr0m75o0b.fsf@gitster.g>
In-Reply-To: <CACS=G2zsJxP+NWuosZyrFGctJptHNYTrULErRo_Ns41KeMuMqA@mail.gmail.com>

Naomi Ibe <naomi.ibeh69@gmail.com> writes:

Show 8 quoted lines

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