[OUTREACHY] Permission To Work On Tasks

[OUTREACHY] Permission To Work On Tasks

[Naomi Ibe]

So I went through this link
https://github.com/gitgitgadget/git/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22
 and I found two issues that interest me.

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.

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

Re: [OUTREACHY] Permission To Work On Tasks

[Junio C Hamano]

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.

Re: [OUTREACHY] Permission To Work On Tasks

[Christian Couder]

On Sat, Oct 7, 2023 at 1:29 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.

Yeah, I agree. In my opinion, a single patch focused on a single file
like builtin/add.c or builtin/branch.c is the best.

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

Yeah, I think this issue, if it is indeed an issue, is not something
easy to "fix" for a newcomer as it requires to be familiar with our
documentation and perhaps our code too, or to research them enough to
understand what a good improvement would be. So you could perhaps do
it, but it would likely require more work.

> 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
> ;-)

I think it's a good idea to ask if the task would be too difficult,
too time consuming, too big or otherwise not appropriate for a
microproject. But true, we don't want applicants to ask for some kind
of permission. We prefer if they just ask for advice.

Re: [OUTREACHY] Permission To Work On Tasks

[Christian Couder]

On Sat, Oct 7, 2023 at 9:20 AM Christian Couder
<christian.couder@gmail.com> wrote:
>
> On Sat, Oct 7, 2023 at 1:29 AM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Naomi Ibe <naomi.ibeh69@gmail.com> writes:

> > > 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.
>
> Yeah, I think this issue, if it is indeed an issue, is not something
> easy to "fix" for a newcomer as it requires to be familiar with our
> documentation and perhaps our code too, or to research them enough to
> understand what a good improvement would be. So you could perhaps do
> it, but it would likely require more work.

Also if it's only a documentation improvement, it might not actually
be a proper microproject as we want them to be "code related".