{"thread":{"id":"58764","subject":"[OUTREACHY][DRAFT Proposal] Unify ref-filter formats with other --pretty formats","startedAt":"2022-11-08T10:55:44Z","lastAt":"2022-11-09T12:37:29Z","messageCount":3,"participants":["Debra Obondo","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"466812","messageId":"CADZqe6cMahXdj0D+QZpHfOzjs9hu1PErjE+qT+PSo1FcbLkWow@mail.gmail.com","threadId":"58764","inReplyTo":null,"subject":"[OUTREACHY][DRAFT Proposal] Unify ref-filter formats with other --pretty formats","fromName":"Debra Obondo","fromEmail":"debraobondo@gmail.com","sentAt":"2022-11-08T10:55:01Z","receivedAt":"2022-11-08T10:55:44Z","isPatch":false,"sender":{"key":"debraobondo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/97498997?v=4"},"body":"Hello Team,\nThis is a draft proposal for the Outreachy Internship, could I kindly\nhave your reviews on it.\nhttps://docs.google.com/document/d/11HX9dkEH--ZfXBTRWJ8rhGnlf3Bj_n_4U2Z-qgbDYVM/edit?usp=sharing\n\nBelow is its basic structure:\n\nUNIFY ref-filter FORMATS WITH OTHER --pretty FORMATS\n\nPersonal Information\n\nName: Debra Obondo\n\nEmail: debraobondo@gmail.com\n\nUniversity: Jomo Kenyatta University of Agriculture and Technology\n\nTelephone Number: +254743635117\n\nCourse: B.Sc Electronic and Computer Engineering\n\nGithub: https://github.com/fobiasic07\n\nLinkedIn: https://www.linkedin.com/in/debra-obondo\n\nTimezone: Nairobi (UTC+3)\n\nLocation: Nairobi, Kenya\n\n\nAbstract\n\nGit has an old problem of duplicated implementations of some logic\nsuch as the four different implementations for formatting command\noutputs for different commands. Ref-filter {.c.h} and pretty-lib\n{.c.h} formatting logic have been no different and require(/d)\nunification, which will help to simplify adding new functionality as\nGit continues to develop.\n\n\nThis project was initially proposed by Hariom Verma following his FOSS\ncontributions to Git and Olga<olyatelezhnaya@gmail.com>’s work on\n‘Unifying Git’s format languages’.\n\n\nIn his final report, he had completed almost all pretty format\nimplementation with a few challenges :\n\n30% Log related failing tests on branch pretty-lib-2.0.2\n\nInability of pretty-lib {.c.h} to handle unknown formatting options.\n\nMailmap logic in ref-filter requires modification due to the new email\noptions which do not allow rebasing and consequently affects the MBOX\ncommit format.\n\nMBOX commit format.\n\nCompleting the work and Rebasing a few other pretty-lib branches with\nfeatures such as fix-graph3 using Junio's way to pretty-lib-2.0.2\n\n\nHe also brought attention to :\n\nOlga’s remaining work https://github.com/telezhnaya/git/commits/format\n\n\nThe purpose of this Internship Project is to solve the challenges,\nsubmit well-functioning patches and increase functionality and\nsimplicity in pretty-lib {.c.h}.\n\nDeliverables\n\nThe purpose of this project having been to improve and easen the\nfunctionality of pretty, I aim to deliver in the following:\n\nWorking on failing formats to pass tests and maintain desired functionality.\n\nEasen error identification when handling unknown formats.\n\nUpdate MBOX commit format so that it still holds initial settings with\nadditional functionality.\n\nModifying mailmap logic to allow additional application.\n\nFinishing work in other pretty-lib branches and merging with original\nonce tests are passed successfully.\n\nUpdate documentation for ease of understanding\n\nFinal report on the improvements made and their importance.\n\n\nWork that may be done if the above is completed before the end of the\nproject timeline:\n\nUnderstanding Olga’s work in depth.\n\nWorking on the formats in ref-filter that were being adopted from cat-file.\n\nWrite and run passing tests for the formats when using ref-filter.\n\nWorking on expanded and added cat-file formats.\n\nUpdate documentation on both cat-file and ref-filter work related to\nOlga’s work.\n\n\nIn the case of the outreachy timeline having been passed, I plan to\nwork on this during the two months left in my long after-semester\nbreak to further my knowledge on git and remain an active member of\nthe git community.\n\n\nProject Implementation\n\nThe project will be done using Git, Bash Scripting and C (and likely Google;-)\n\n\nSince I am about to finish my current semester, my exams (5th - 16th\nDecember)  are likely to clash with the start of the internship, but\nnot to worry, since after that, I will be able to give my full-time\nconcentration to this project, about 45-50 Hours or more a week, since\nI will be having an academic year break between then and 8th May 2023\nbefore my final academic year begins.. Below is my programming plan.\n\n\nProgramming Plan\n\nI have divided my programming plan into 5 parts, which would be as follows:\n\nPART 1(Pre- Program);\n\nThis is before the official start of the program, between now and 5th Dec :\n\nI plan to familiarize myself better with the community, submit a few\npatches using 'git send-email', as it enables ease of communication on\nvarious contributions and projects as compared to gitgitgadget.\nLearning and understanding the logic and format functionality of both\nthe pretty and ref-filter commands is a priority to easen working on\nthe project later on. If accepted, plan for the required weekly\nmentor-mentee meeting time(s). I also plan to understand the function\ndie() by going through this project: Issue #635\n\nPART 2 (Phase 1); 5th Dec -2nd Jan:\n\nThis is during the first third of the program:\n\nWorking with mentors to identify the log-related failing test formats.\n\n Reworking the failing formats to pass the tests, while still\nfunctioning in the required unified logic.\n\nShare the first two blogs via my social media handles.\n\n Update Documentation.\n\nStart on 'handling unknown formatting options'\n\n Feedback #1 submission\n\nPART 3 (Phase 2); 3rd Jan - 1st Feb:\n\nDuring the second third of the program:\n\n Working on the die() function, to figure out the best way to handle\nunknown formatting options by pretty, be it creating a new 'die'/end\nprocess function with more options,, mentor and community discussion\nwill help.\n\n Feedback #2 submission\n\n Modifying mailmap logic in ref-filter to allow rebasing, in turn,\nworking on the MBOX commit format.\n\nShare my learning progress and challenges in other two blogs.\n\n Update Documentation.\n\n Feedback #3 submission.\n\nPART 4 (Phase 3): 2nd Feb - 1st March:\n\nDuring the final third of the program:\n\n Working on the other pretty lib branches (yet to go through them) and\nrebasing/ merging the features to pretty-lib 2.0.2.\n\n Sharing my experience with Git as an FOSS community and giving my\nfinal report through blogs.\n\n Fix any bugs that may be left and 'polish' the work on --pretty and ref-filter.\n\n Update Documentation.\n\nFeedback #4 submission.\n\nPart 5(Post-program):\n\nAfter gaining many skills from working on the above, I believe I will\nhave the capacity to take on Olga's work during the remaining 2 month\nbreak that I will be left with. In the case of similar projects during\nGSoC 23';-) or Outreachy May to August, I will also be willing to\nmentor, since teaching helps us learn more.\n\nPerceived Obstacles and Challenges\n\nTest Fails\n\nThis is always a possible occurrence in programming, therefore,\ntogether with my mentors and the git community, solutions are highly\nlikely to emerge.\n\nMaintaining compatibility for both newer and older systems\n\nThis is majorly in the mbox commit format and mailmap logic issue.\nFurther research and various opinions will lead to us finding the best\nway forward.\n\nOverflow of work past the internship period\n\nThis is likely to occur with rebasing of the other pretty-lib branches\nand Olga’s work and can easily be dealt with by me giving more time in\nthe case of not reaching my timeline personal set deadlines.\n\nAbout Me\n\nI am a fourth year B.Sc student taking Electronics and Computer\nEngineering at Jomo Kenyatta University of Agriculture and Technology,\nKenya. I have also been a member of the ALX-Africa-2022 Software\nProgramme.\n\n\nI recently decided to venture into software as my career path. This\nwas during my attachment at Gearbox Academy , where I gained skills in\nWeb Development, Microcontroller processing and 3D Design.\n\n\nI have experience with C from my coursework and ALX practice and level\n3 skills and knowledge in BASH scripting and Git, which I would like\nto further improve on. I believe contributing to this open source\nproject will help me to further grow my skills and widen my knowledge\non FOSS as a whole.\n\n\nEquipped with this chance, I shall also use the skills learnt to help\nfuture developers on similar projects and to continue contributing to\ngit and other open-source projects.\n\n\nRequirements\n\n\nThis is the micro project required while submitting the proposal for\nthe Outreachy 2022 program:\nhttps://lore.kernel.org/git/pull.1372.git.git.1667150441883.gitgitgadget@gmail.com\n\n\nDescription:\n\nOlder test scripts have used the command 'test -' to verify the\npresence or absence of features such as files, directories and\nsymbolic links. This however requires slightly complicated uses, such\nas 'test ! -f '. The helper functions 'test_path_is_' located in\nt/test-lib-functions.sh have taken into account all scenarios of the\n'test -*' to reduce errors. This was a microproject to replace them\nwith the helper functions.\n\n\nTest script to verify the presence/absence of files, paths,\ndirectories, symboliclinks and many other features in mv command are\nusing the command format\n\n\n'test -(e|f|s|h|...)’\n\n\nReplace them with helper functions of format\n\n\n'test_path_is_*'\n\n\nAt the time of submission, this patch has been queued into ‘seen’\npreparation for merging into next and eventually master: t7001-mv.sh\ncommit\n\nMotivation\n\nGit members are welcoming, I feel it will be a good learning community\nfor me to grow as an Open source contributor and software programmer,\nwhich is one of my personal targets. During my contribution, I\nreceived understandable feedback in a short period of time and was\nable to make ‘polished’ and ‘out-of-the-blue’ patches as required.\n(It’s part of the conversation thread in my microproject) This brought\nto my awareness that git is an easily approachable community for any\nprogramming challenges faced.\n\nReferences\n\nGit SoC 2022 Ideas : https://git.github.io/SoC-2022-Ideas/\n\nGit Soc 2022 Applicant Microprojects :\nhttps://git.github.io/SoC-2022-Microprojects/\n\nThe Final Report by Hariom Verma:\nhttps://harry-hov.github.io/blogs/posts/the-final-report\n\nLooking forward to your responses.\n\nKind regards,\nDebra obondo.\n"},{"id":"466945","messageId":"CAP8UFD0FurXUo79Liu2iaging9ZzXFEjyjFq8VJ3Htkat-+pqw@mail.gmail.com","threadId":"58764","inReplyTo":"CADZqe6cMahXdj0D+QZpHfOzjs9hu1PErjE+qT+PSo1FcbLkWow@mail.gmail.com","subject":"Re: [OUTREACHY][DRAFT Proposal] Unify ref-filter formats with other --pretty formats","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2022-11-09T11:49:27Z","receivedAt":"2022-11-09T11:49:44Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Tue, Nov 8, 2022 at 11:55 AM Debra Obondo <debraobondo@gmail.com> wrote:\n>\n> Hello Team,\n> This is a draft proposal for the Outreachy Internship, could I kindly\n> have your reviews on it.\n> https://docs.google.com/document/d/11HX9dkEH--ZfXBTRWJ8rhGnlf3Bj_n_4U2Z-qgbDYVM/edit?usp=sharing\n\nI am going to review it even if it's a bit late to be taken into\naccount. (I think the Contribution Period ended on Nov 4, and today,\nNov 9, is the last day for us to select interns.)\n\nThank you anyway for being interested in this project and for sending\nthis proposal!\n\n> Below is its basic structure:\n>\n> UNIFY ref-filter FORMATS WITH OTHER --pretty FORMATS\n\n[...]\n\n> Abstract\n>\n> Git has an old problem of duplicated implementations of some logic\n> such as the four different implementations for formatting command\n> outputs for different commands.\n\nI am not sure if there are still four different implementations. As\nfar as I remember, we have been trying to unify:\n\n  - `git for-each-ref`, `git branch` and `git tag` formats into the\nref-filter formats:\n\ndone by Karthik Nayak (GSoC 2015)\n\n  -  `git cat-file` formats and the ref-filter formats:\n\nstarted by Olga Telezhnaya (Outreachy 20217-2018),\ncontinued by ZheNing Hu (GSoC 2021),\nbut still not finished due to tricky performance issues\n\n  - ref-filter formats and pretty formats:\n\nstarted by Hariom Verma (GSoC 2020)\ncontinued a bit by Jaydeep Das (GSoC 2022)\nbut still not finished (although there doesn't seem to be hard issues),\nso proposed for Outreachy 2022-2023\n\n> Ref-filter {.c.h} and pretty-lib\n> {.c.h} formatting logic\n\nI am not sure it's worth talking about filenames as early in this\nproposal. Also, on the current master branch, code for the pretty\nformats seems to be in pretty.{c,h} not pretty-lib.{c,h}.\n\n> have been no different and require(/d)\n> unification, which will help to simplify adding new functionality as\n> Git continues to develop.\n>\n> This project was initially proposed by Hariom Verma following his FOSS\n> contributions to Git and Olga<olyatelezhnaya@gmail.com>’s work on\n> ‘Unifying Git’s format languages’.\n\nSee above for more details. (Yeah, Olga worked on a project named\n‘Unifying Git’s format languages’, but it was actually about using\nref-filter formats in `git cat-file`.)\n\n> In his final report, he had completed almost all pretty format\n> implementation with a few challenges :\n>\n> 30% Log related failing tests on branch pretty-lib-2.0.2\n>\n> Inability of pretty-lib {.c.h} to handle unknown formatting options.\n\nYeah, Hariom wanted to create pretty-lib.{c,h} files, but I think this\nwas not necessary so it wasn't done.\n\n> Mailmap logic in ref-filter requires modification due to the new email\n> options which do not allow rebasing and consequently affects the MBOX\n> commit format.\n>\n> MBOX commit format.\n>\n> Completing the work and Rebasing a few other pretty-lib branches with\n> features such as fix-graph3 using Junio's way to pretty-lib-2.0.2\n\nI think it would have been better to summarize things a bit better,\nand to avoid talking about low level details that are sometimes not\nrelevant anymore, like pretty-lib.\n\n> He also brought attention to :\n>\n> Olga’s remaining work https://github.com/telezhnaya/git/commits/format\n>\n> The purpose of this Internship Project is to solve the challenges,\n> submit well-functioning patches and increase functionality and\n> simplicity in pretty-lib {.c.h}.\n\nHere also I am not sure it's a good idea to talk about pretty-lib.\n\n> Deliverables\n>\n> The purpose of this project having been to improve and easen the\n> functionality of pretty, I aim to deliver in the following:\n>\n> Working on failing formats to pass tests and maintain desired functionality.\n>\n> Easen error identification when handling unknown formats.\n>\n> Update MBOX commit format so that it still holds initial settings with\n> additional functionality.\n>\n> Modifying mailmap logic to allow additional application.\n>\n> Finishing work in other pretty-lib branches and merging with original\n> once tests are passed successfully.\n>\n> Update documentation for ease of understanding\n>\n> Final report on the improvements made and their importance.\n\nI think it would be nice if the different pretty formats for which\nsome work is needed could be listed along with the work needed.\n\n> Work that may be done if the above is completed before the end of the\n> project timeline:\n>\n> Understanding Olga’s work in depth.\n>\n> Working on the formats in ref-filter that were being adopted from cat-file.\n\nThis project is not about using ref-filter formats in `git cat-file`.\nYeah, it would be very nice if you could do it, but it's very unlikely\nthat you could do it on top of unifying the ref-filter and pretty\nformats. (This has been discussed recently on the mailing list between\nZheNing Hu and me.)\n\n[...]\n\n> In the case of the outreachy timeline having been passed, I plan to\n> work on this during the two months left in my long after-semester\n> break to further my knowledge on git and remain an active member of\n> the git community.\n\nNice!\n\n[...]\n\n> Below is my programming plan.\n>\n> Programming Plan\n>\n> I have divided my programming plan into 5 parts, which would be as follows:\n\nI have basically the same comments for this section as for the previous section.\n\n[...]\n\n> This is the micro project required while submitting the proposal for\n> the Outreachy 2022 program:\n> https://lore.kernel.org/git/pull.1372.git.git.1667150441883.gitgitgadget@gmail.com\n\nThanks for working on this micro-project!\n\n> Motivation\n>\n> Git members are welcoming, I feel it will be a good learning community\n> for me to grow as an Open source contributor and software programmer,\n> which is one of my personal targets. During my contribution, I\n> received understandable feedback in a short period of time and was\n> able to make ‘polished’ and ‘out-of-the-blue’ patches as required.\n> (It’s part of the conversation thread in my microproject) This brought\n> to my awareness that git is an easily approachable community for any\n> programming challenges faced.\n\nThanks for the kind words!\n\nChristian.\n"},{"id":"466946","messageId":"CADZqe6fXb7KtG95qfE6XeCiLodTB-17RWsCT7YE6DPOkb_D+bQ@mail.gmail.com","threadId":"58764","inReplyTo":"CAP8UFD0FurXUo79Liu2iaging9ZzXFEjyjFq8VJ3Htkat-+pqw@mail.gmail.com","subject":"Re: [OUTREACHY][DRAFT Proposal] Unify ref-filter formats with other --pretty formats","fromName":"Debra Obondo","fromEmail":"debraobondo@gmail.com","sentAt":"2022-11-09T12:37:10Z","receivedAt":"2022-11-09T12:37:29Z","isPatch":false,"sender":{"key":"debraobondo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/97498997?v=4"},"body":"Hello Christian\n\nOn Wed, Nov 9, 2022 at 2:49 PM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> Hi,\n>\n> On Tue, Nov 8, 2022 at 11:55 AM Debra Obondo <debraobondo@gmail.com> wrote:\n> >\n> > Hello Team,\n> > This is a draft proposal for the Outreachy Internship, could I kindly\n> > have your reviews on it.\n> > https://docs.google.com/document/d/11HX9dkEH--ZfXBTRWJ8rhGnlf3Bj_n_4U2Z-qgbDYVM/edit?usp=sharing\n>\n> I am going to review it even if it's a bit late to be taken into\n> account. (I think the Contribution Period ended on Nov 4, and today,\n> Nov 9, is the last day for us to select interns.)\n\nThank you for taking your time to review my proposal despite its\nlateness, I sincerely appreciate it. I've been at the period in the\nsemester where balance gets a little bit 'tricky', so, I was putting\nin my last minute efforts. I had, however, submitted some of the\n'required' details in the Outreachy portal before the deadline .\n>\n> Thank you anyway for being interested in this project and for sending\n> this proposal!\n>\n> > Below is its basic structure:\n> >\n> > UNIFY ref-filter FORMATS WITH OTHER --pretty FORMATS\n>\n> [...]\n>\n> > Abstract\n> >\n> > Git has an old problem of duplicated implementations of some logic\n> > such as the four different implementations for formatting command\n> > outputs for different commands.\n>\n> I am not sure if there are still four different implementations. As\n> far as I remember, we have been trying to unify:\n>\n>   - `git for-each-ref`, `git branch` and `git tag` formats into the\n> ref-filter formats:\n>\n> done by Karthik Nayak (GSoC 2015)\n>\n>   -  `git cat-file` formats and the ref-filter formats:\n>\n> started by Olga Telezhnaya (Outreachy 20217-2018),\n> continued by ZheNing Hu (GSoC 2021),\n> but still not finished due to tricky performance issues\n>\n>   - ref-filter formats and pretty formats:\n>\n> started by Hariom Verma (GSoC 2020)\n> continued a bit by Jaydeep Das (GSoC 2022)\n> but still not finished (although there doesn't seem to be hard issues),\n> so proposed for Outreachy 2022-2023\n>\n> > Ref-filter {.c.h} and pretty-lib\n> > {.c.h} formatting logic\n>\n> I am not sure it's worth talking about filenames as early in this\n> proposal. Also, on the current master branch, code for the pretty\n> formats seems to be in pretty.{c,h} not pretty-lib.{c,h}.\n>\nI understand, I am still doing further research on this project, to\nunderstand it better. I was also following Hariom's commits and\nbranches, which could have caused the confusion of me naming it\npretty-lib(as he has) instead of pretty (as is in git). I am yet to\nbegin looking through Jaydeep's work as well.\n\n> > have been no different and require(/d)\n> > unification, which will help to simplify adding new functionality as\n> > Git continues to develop.\n> >\n> > This project was initially proposed by Hariom Verma following his FOSS\n> > contributions to Git and Olga<olyatelezhnaya@gmail.com>’s work on\n> > ‘Unifying Git’s format languages’.\n>\n> See above for more details. (Yeah, Olga worked on a project named\n> ‘Unifying Git’s format languages’, but it was actually about using\n> ref-filter formats in `git cat-file`.)\n>\n> > In his final report, he had completed almost all pretty format\n> > implementation with a few challenges :\n> >\n> > 30% Log related failing tests on branch pretty-lib-2.0.2\n> >\n> > Inability of pretty-lib {.c.h} to handle unknown formatting options.\n>\n> Yeah, Hariom wanted to create pretty-lib.{c,h} files, but I think this\n> was not necessary so it wasn't done.\n>\n> > Mailmap logic in ref-filter requires modification due to the new email\n> > options which do not allow rebasing and consequently affects the MBOX\n> > commit format.\n> >\n> > MBOX commit format.\n> >\n> > Completing the work and Rebasing a few other pretty-lib branches with\n> > features such as fix-graph3 using Junio's way to pretty-lib-2.0.2\n>\n> I think it would have been better to summarize things a bit better,\n> and to avoid talking about low level details that are sometimes not\n> relevant anymore, like pretty-lib.\n>\n> > He also brought attention to :\n> >\n> > Olga’s remaining work https://github.com/telezhnaya/git/commits/format\n> >\n> > The purpose of this Internship Project is to solve the challenges,\n> > submit well-functioning patches and increase functionality and\n> > simplicity in pretty-lib {.c.h}.\n>\n> Here also I am not sure it's a good idea to talk about pretty-lib.\n>\n> > Deliverables\n> >\n> > The purpose of this project having been to improve and easen the\n> > functionality of pretty, I aim to deliver in the following:\n> >\n> > Working on failing formats to pass tests and maintain desired functionality.\n> >\n> > Easen error identification when handling unknown formats.\n> >\n> > Update MBOX commit format so that it still holds initial settings with\n> > additional functionality.\n> >\n> > Modifying mailmap logic to allow additional application.\n> >\n> > Finishing work in other pretty-lib branches and merging with original\n> > once tests are passed successfully.\n> >\n> > Update documentation for ease of understanding\n> >\n> > Final report on the improvements made and their importance.\n>\n> I think it would be nice if the different pretty formats for which\n> some work is needed could be listed along with the work needed.\n>\nI will continue to edit my proposal as I do more research, despite the\npassed deadline (today), because it will help me, if not for this\nparticular project, maybe in future, I will be able to apply the\nskills, knowledge, understanding and thought process gained from this\none.\n\n> > Work that may be done if the above is completed before the end of the\n> > project timeline:\n> >\n> > Understanding Olga’s work in depth.\n> >\n> > Working on the formats in ref-filter that were being adopted from cat-file.\n>\n> This project is not about using ref-filter formats in `git cat-file`.\n> Yeah, it would be very nice if you could do it, but it's very unlikely\n> that you could do it on top of unifying the ref-filter and pretty\n> formats. (This has been discussed recently on the mailing list between\n> ZheNing Hu and me.)\n>\nI will look deeper into it, since well, I will still be having the 4\nmonths holiday's time.\n> [...]\n>\n> > In the case of the outreachy timeline having been passed, I plan to\n> > work on this during the two months left in my long after-semester\n> > break to further my knowledge on git and remain an active member of\n> > the git community.\n>\n> Nice!\n>\n> [...]\n>\n> > Below is my programming plan.\n> >\n> > Programming Plan\n> >\n> > I have divided my programming plan into 5 parts, which would be as follows:\n>\n> I have basically the same comments for this section as for the previous section.\n>\n> [...]\n>\n> > This is the micro project required while submitting the proposal for\n> > the Outreachy 2022 program:\n> > https://lore.kernel.org/git/pull.1372.git.git.1667150441883.gitgitgadget@gmail.com\n>\n> Thanks for working on this micro-project!\n>\n> > Motivation\n> >\n> > Git members are welcoming, I feel it will be a good learning community\n> > for me to grow as an Open source contributor and software programmer,\n> > which is one of my personal targets. During my contribution, I\n> > received understandable feedback in a short period of time and was\n> > able to make ‘polished’ and ‘out-of-the-blue’ patches as required.\n> > (It’s part of the conversation thread in my microproject) This brought\n> > to my awareness that git is an easily approachable community for any\n> > programming challenges faced.\n>\n> Thanks for the kind words!\n>\n> Christian.\n\nThank you for the feedback. I would still love to be considered in the\ncase that Outreachy creates space for companies to accept more\ninterns. I will also send a V2 for the proposal soon.\n\nThanks,\nDebra\n"}]}