Re: [OUTREACHY] Permission To Work On Tasks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Naomi Ibe <naomi.ibeh69@xxxxxxxxx> 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux