{"thread":{"id":"60319","subject":"[OUTREACHY] Permission To Work On Tasks","startedAt":"2023-10-06T22:45:23Z","lastAt":"2023-10-09T13:45:57Z","messageCount":4,"participants":["Naomi Ibe","Junio C Hamano","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"482773","messageId":"CACS=G2zsJxP+NWuosZyrFGctJptHNYTrULErRo_Ns41KeMuMqA@mail.gmail.com","threadId":"60319","inReplyTo":null,"subject":"[OUTREACHY] Permission To Work On Tasks","fromName":"Naomi Ibe","fromEmail":"naomi.ibeh69@gmail.com","sentAt":"2023-10-06T22:41:35Z","receivedAt":"2023-10-06T22:45:23Z","isPatch":false,"sender":{"key":"naomi.ibeh69@gmail.com","avatar":"https://avatars.githubusercontent.com/u/104323769?v=4"},"body":"So I went through this link\nhttps://github.com/gitgitgadget/git/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22\n and I found two issues that interest me.\n\nFirst issue is here https://github.com/gitgitgadget/git/issues/635 ,\ninvolving changing the \"die()\" error msg outputs to all lowercase. I\nfound a few files here https://github.com/git/git/tree/master/builtin\nwhere the \"die()\" error msg had some uppercase in them (add.c in lines\n185, 203, 205, 211 and 571) (branch.c in lines 521, 525, 581, 597,\n599, 627, 629, 643, 650, 652, 776, 926, 954 and 968). If I'm allowed\nto work on this issue, how many files should I edit? The last closed\nissues related to this issue had edited five files.\n\nSecond issue is this https://github.com/gitgitgadget/git/issues/302 .\nIs it still available to be worked on? I notice it was opened in 2019\n"},{"id":"482778","messageId":"xmqqr0m75o0b.fsf@gitster.g","threadId":"60319","inReplyTo":"CACS=G2zsJxP+NWuosZyrFGctJptHNYTrULErRo_Ns41KeMuMqA@mail.gmail.com","subject":"Re: [OUTREACHY] Permission To Work On Tasks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-06T23:28:52Z","receivedAt":"2023-10-06T23:29:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Naomi Ibe writes:\n\n> First issue is here https://github.com/gitgitgadget/git/issues/635 ,\n> involving changing the \"die()\" error msg outputs to all lowercase. I\n> found a few files here https://github.com/git/git/tree/master/builtin\n> where the \"die()\" error msg had some uppercase in them (add.c in lines\n> 185, 203, 205, 211 and 571) (branch.c in lines 521, 525, 581, 597,\n> 599, 627, 629, 643, 650, 652, 776, 926, 954 and 968). If I'm allowed\n> to work on this issue, how many files should I edit? The last closed\n> issues related to this issue had edited five files.\n\nAs the \"general microproject information\" page says, it is a good\nidea to do just one quality-focused microproject per applicant.\n\nIf I were on the receiving end to review such a patch, I would\nprobably find it is too boring a burden if it had several unrelated\ncommands covered by a single patch, and would stop reading in the\nmiddle.\n\nIf I were on the sending end to work on them for real (not as \"dip\nmy toe in the water and say hello to the more experienced\ndevelopers\" exercise), I would probably prepare a series of patches,\none for each git subcommand (e.g. \"add\", \"branch\", \"log\", etc.), and\nfor shared infrastructure files, one for each subsystem that they\nare part of (this is harder to do for a new person who do not know\nwhat subsystems exist, and which files implement which subsystem),\nbut for a microproject, I would say a single file under builtin/*\nhierarchy would be a good size.\n\n> Second issue is this https://github.com/gitgitgadget/git/issues/302 .\n> Is it still available to be worked on? I notice it was opened in 2019\n\nStepping back a bit, do you agree with what the issue says?\nRemember, these \"issue\"s are merely one person's opinion and not\nendorsed by the community.\n\nBefore you ask \"is it still available\", do you know the current\nstatus (not the status of the \"issue\")? Have you looked at \"git\ncommit --help\" to find it out yourself to see if \"now\" is singled\nout? Here is what we say in our documentation:\n\n In addition to recognizing all date formats above, the --date\n option will also try to make sense of other, more human-centric\n date formats, such as relative dates like \"yesterday\" or \"last\n Friday at noon\".\n\nSo apparently it is still \"available\". It is a different matter how\nwell a patch that adds \"now\" to the examples listed there will be\naccepted, though. During a microproject, one of the things new\ncontributors are expected to learn is to convince others the cause\nof their patches with the proposed commit log message well.\n\nFinally, you do not need to obtain permission to work on anything\naround here. You work on what interests you, send the result (or\nsend request for help, to which others may offer advices if the\nproblem you are solving looks interesting) to be reviewed, and will\nbe thanked for working on it when your patch is applied. To avoid\nduplicated work, you might want to say \"I'm interested in doing\nthis, but is anybody already doing it? If so I'll avoid stepping on\ntheir toes\", but otherwise, you are expected to go wild on your own\n;-)\n\nHave fun.\n"},{"id":"482786","messageId":"CAP8UFD0PKAGchx5iqyZqCdua-KYJcrmO2FfNf_vt7xs=+7YL4Q@mail.gmail.com","threadId":"60319","inReplyTo":"xmqqr0m75o0b.fsf@gitster.g","subject":"Re: [OUTREACHY] Permission To Work On Tasks","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2023-10-07T07:20:24Z","receivedAt":"2023-10-07T07:20:42Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sat, Oct 7, 2023 at 1:29 AM Junio C Hamano wrote:\n>\n> Naomi Ibe writes:\n>\n> > First issue is here https://github.com/gitgitgadget/git/issues/635 ,\n> > involving changing the \"die()\" error msg outputs to all lowercase. I\n> > found a few files here https://github.com/git/git/tree/master/builtin\n> > where the \"die()\" error msg had some uppercase in them (add.c in lines\n> > 185, 203, 205, 211 and 571) (branch.c in lines 521, 525, 581, 597,\n> > 599, 627, 629, 643, 650, 652, 776, 926, 954 and 968). If I'm allowed\n> > to work on this issue, how many files should I edit? The last closed\n> > issues related to this issue had edited five files.\n>\n> As the \"general microproject information\" page says, it is a good\n> idea to do just one quality-focused microproject per applicant.\n>\n> If I were on the receiving end to review such a patch, I would\n> probably find it is too boring a burden if it had several unrelated\n> commands covered by a single patch, and would stop reading in the\n> middle.\n>\n> If I were on the sending end to work on them for real (not as \"dip\n> my toe in the water and say hello to the more experienced\n> developers\" exercise), I would probably prepare a series of patches,\n> one for each git subcommand (e.g. \"add\", \"branch\", \"log\", etc.), and\n> for shared infrastructure files, one for each subsystem that they\n> are part of (this is harder to do for a new person who do not know\n> what subsystems exist, and which files implement which subsystem),\n> but for a microproject, I would say a single file under builtin/*\n> hierarchy would be a good size.\n\nYeah, I agree. In my opinion, a single patch focused on a single file\nlike builtin/add.c or builtin/branch.c is the best.\n\n> > Second issue is this https://github.com/gitgitgadget/git/issues/302 .\n> > Is it still available to be worked on? I notice it was opened in 2019\n>\n> Stepping back a bit, do you agree with what the issue says?\n> Remember, these \"issue\"s are merely one person's opinion and not\n> endorsed by the community.\n>\n> Before you ask \"is it still available\", do you know the current\n> status (not the status of the \"issue\")? Have you looked at \"git\n> commit --help\" to find it out yourself to see if \"now\" is singled\n> out? Here is what we say in our documentation:\n>\n> In addition to recognizing all date formats above, the --date\n> option will also try to make sense of other, more human-centric\n> date formats, such as relative dates like \"yesterday\" or \"last\n> Friday at noon\".\n>\n> So apparently it is still \"available\". It is a different matter how\n> well a patch that adds \"now\" to the examples listed there will be\n> accepted, though. During a microproject, one of the things new\n> contributors are expected to learn is to convince others the cause\n> of their patches with the proposed commit log message well.\n\nYeah, I think this issue, if it is indeed an issue, is not something\neasy to \"fix\" for a newcomer as it requires to be familiar with our\ndocumentation and perhaps our code too, or to research them enough to\nunderstand what a good improvement would be. So you could perhaps do\nit, but it would likely require more work.\n\n> Finally, you do not need to obtain permission to work on anything\n> around here. You work on what interests you, send the result (or\n> send request for help, to which others may offer advices if the\n> problem you are solving looks interesting) to be reviewed, and will\n> be thanked for working on it when your patch is applied. To avoid\n> duplicated work, you might want to say \"I'm interested in doing\n> this, but is anybody already doing it? If so I'll avoid stepping on\n> their toes\", but otherwise, you are expected to go wild on your own\n> ;-)\n\nI think it's a good idea to ask if the task would be too difficult,\ntoo time consuming, too big or otherwise not appropriate for a\nmicroproject. But true, we don't want applicants to ask for some kind\nof permission. We prefer if they just ask for advice.\n"},{"id":"482864","messageId":"CAP8UFD2FNGJJahbZtszB-ao1qbr6kYe4ks=u5E5zM-aQYjSkOw@mail.gmail.com","threadId":"60319","inReplyTo":"CAP8UFD0PKAGchx5iqyZqCdua-KYJcrmO2FfNf_vt7xs=+7YL4Q@mail.gmail.com","subject":"Re: [OUTREACHY] Permission To Work On Tasks","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2023-10-09T13:45:13Z","receivedAt":"2023-10-09T13:45:57Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sat, Oct 7, 2023 at 9:20 AM Christian Couder\n wrote:\n>\n> On Sat, Oct 7, 2023 at 1:29 AM Junio C Hamano wrote:\n> >\n> > Naomi Ibe writes:\n\n> > > Second issue is this https://github.com/gitgitgadget/git/issues/302 .\n> > > Is it still available to be worked on? I notice it was opened in 2019\n> >\n> > Stepping back a bit, do you agree with what the issue says?\n> > Remember, these \"issue\"s are merely one person's opinion and not\n> > endorsed by the community.\n> >\n> > Before you ask \"is it still available\", do you know the current\n> > status (not the status of the \"issue\")? Have you looked at \"git\n> > commit --help\" to find it out yourself to see if \"now\" is singled\n> > out? Here is what we say in our documentation:\n> >\n> > In addition to recognizing all date formats above, the --date\n> > option will also try to make sense of other, more human-centric\n> > date formats, such as relative dates like \"yesterday\" or \"last\n> > Friday at noon\".\n> >\n> > So apparently it is still \"available\". It is a different matter how\n> > well a patch that adds \"now\" to the examples listed there will be\n> > accepted, though. During a microproject, one of the things new\n> > contributors are expected to learn is to convince others the cause\n> > of their patches with the proposed commit log message well.\n>\n> Yeah, I think this issue, if it is indeed an issue, is not something\n> easy to \"fix\" for a newcomer as it requires to be familiar with our\n> documentation and perhaps our code too, or to research them enough to\n> understand what a good improvement would be. So you could perhaps do\n> it, but it would likely require more work.\n\nAlso if it's only a documentation improvement, it might not actually\nbe a proper microproject as we want them to be \"code related\".\n"}]}