Re: [GSoC][Draft Proposal v2] Finish converting git submodule to builtin

[Christian Couder <christian.couder@gmail.com>]

On Mon, Apr 12, 2021 at 7:56 AM Atharva Raykar <raykar.ath@gmail.com> wrote:
> On 12-Apr-2021, at 01:02, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
> > On 11/04/21 3:10 pm, Atharva Raykar wrote:

> >> The example I gave for how to handle the presence of the remote flag
> >> and the function that performs the module updation method (ie, the `case`
> >> on line 611) was just to illustrate the above workflow, rather than say
> >> that this is how I will exactly do it.
> >> I also would like to know what level of granularity is ideal for the
> >> proposal. For now I have tried to keep it at "whatever I will surely
> >> follow through when I work on the project", which at the moment is the
> >> covered by the four points I mentioned above.
> >> If I go too much into detail about the functions and arguments
> >> of every helper in my example, I will feel compelled to do the same for
> >> the `git submodule add` example. I also will have to reason more carefully
> >> because I do not want to end up in a situation where I do not actually
> >> stick to my proposal all that much, because I realise in my investigation
> >> phase that there is a different, much better way.
> >> Do let me know what is preferred.
> >
> > It makes sense that you don't want to go into too much detail in your
> > proposal. I think Christian wasn't expecting it either. As far as I
> > understand, he was just trying to make your proposal clear to the person
> > who reads it. Just mentioning something like,
> >
> >  This would perform the work being done by the shell script past the
> >  flags being parsed and make the necessary call to `update_clone()',
> >  which returns information about the cloned modules.
> >
> > is not clear as it doesn't say how you're "thinking" the function would
> > return information. Mention this would be helpful for the reader to know
> > what your expectations are and if they need any correction. So, it is
> > better to mention such related information to make your proposal
> > complete. The high-level flow looks good to me.
>
> Alright, I get what you mean. I hope my v3 communicated my intention
> more clearly. Translating my thoughts to text is hard work, and the
> good part of revisiting my proposal and fleshing out the details is
> it is forcing me to understand the problem better :)

Yeah, the idea is that you should try to show in your proposal that
you have understood some of the problems well enough. If there are
things that are not clear or not very detailed, they are not very
useful as they won't show us that you have understood much. It's
better to focus on a few things or examples and explain them clearly
and with enough detail, than to try to cover a lot of ground in a
vague way.

In other words if you can explain well a sensible plan to convert a
small part of the code, and give sensible details about that small
part, we can have trust that you will manage to do it for the whole
project even if some of the details change.