Hi Christian, Took a while. I hope we would be in a habit to connect to old conversations. :) On Mon, Apr 25, 2022 at 2:07 PM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > Hi Tapasweni, > > On Fri, Apr 22, 2022 at 12:40 PM Tapasweni Pathak > <tapaswenipathak@xxxxxxxxx> wrote: > > > > Hi Taylor, Hi Junio, > > > > I have added the mailing list (++git@xxxxxxxxxxxxxxx) in this email, > > hope now it lands better in your mailbox. > > > > I would be happy to take these tasks, not that I require any > > mentorship but to work with folks who are involved. > > I am sure that there will be folks who are involved who will work with > you if you select one of the projects we suggested. We don't suggest > projects we are not interested in. The old timers who suggest them and > are willing to mentor usually do get involved in them. Yes, sure, sending the initial draft for git-scm.com in the next email. I will soon loop in the plan/timeline for two other tasks, described. > > > I have had times > > where my work has not been seen for quarters and then closed after > > reviews cycles, never let it re-happen. > > We cannot guarantee that your work will be merged, as some better > solution might be found, or someone else will decide to do it in > another way and it might turn out to be better. But otherwise you can > be pretty sure that your work will get reviewed. It might take some > time and we might ask for a lot of changes in the reviews though. Sure! > > > It is a nice and respectful way to say, already deeply involved folks > > as mentors, for someone who is entering the org or community. Not that > > I require any tech or engineering help or otherwise, I mostly work > > independently, just don't want to go my work stale and be clear on > > what exactly is required (before or after a discussion, rather w/ or > > w/o any discussions) > > I think we are open to answering specific questions about what is > required for the work we suggest. We might sometimes be wrong though > and realize it later, so the requirements (or sometimes the whole > solution we suggest) could change along the way. That's how software > development works. And even in this case the fact that we realize that > our requirements were wrong is an achievement. Agree!
