On Thu, Apr 03, 2025 at 08:56:45PM +0530, Arnav Bhate wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > On Wed, Apr 02, 2025 at 11:44:12PM +0530, Arnav Bhate wrote: > >> ### Timeline > >> > >> #### Pre-GSoC (Until May 8) > >> > >> - Explore the codebase, identifying global variables and how they are > >> used. > >> > >> - Start to identify suitable locations for global variables. > >> > >> #### Community Bonding Period (May 8 - June 1) > >> > >> - Interact with mentor, discussing best ways to refactor various > >> variables and make a plan based on that. > >> > >> - If time is left, start coding early, as my summer break will have > >> started. > >> > >> #### Coding Period (June 2 - August 25) > >> > >> - Modify functions to add an `struct repository` argument where they > >> depend on `the_repository` and replace all occurences of it. > >> > >> - Move global variables to their new locations in various structs, > >> and refactor functions that depend on them to use their new locations. > > > > In large-scale projects like these it typically makes sense to work in > > batches. Instead of having three separate phases to "define the > > problem", "develop the solution" and "deploy the improvement" I would > > strongly encourage you to define and tie together smaller batches of > > work. > > What I meant is, before coding started, I want to finalise all the new > locations for the global variables with my mentor, then I would actually > modify the code in batches, struct-by-struct. Are you suggesting that > the new locations not be finalised beforehand, or are we misinterpreting > each other? The problem I see is that you only have one large "Coding Period". What we would like to see though is that you define smaller, self-contained batches of work that you can try to land individually, as well as an estimation around how long each of these batches will take you to both developend and land in Git itself. Patrick
