How To Pick And Work On A Microproject

How To Pick And Work On A Microproject

[Naomi Ibe]

I have gone through this link
https://git.github.io/General-Microproject-Information/  and I am not
really clear with it especially this line
"Select a microproject and check that it has not yet been taken or
discussed by searching the mailing list. Public Inbox is your friend."
 On the mailing list I see messages with the [PATCH] keyword in front
of them, am I expected to pick one and reply to it? How do I reply
directly under the thread which contains the issue? Please, how do I
find the issue on the Git repository? I checked the repo and could not
find the "issues" section also .
Please HELP!!! Any explanations would be very much appreciated, as I
would prefer to start working on it as early as possible.
Thank you.

Re: How To Pick And Work On A Microproject

[Junio C Hamano]

Naomi Ibe <naomi.ibeh69@gmail.com> writes:

> "Select a microproject and check that it has not yet been taken or
> discussed by searching the mailing list. Public Inbox is your friend."

Yeah, that is VERY unfriendly.  There is no mention on the pool of
microproject ideas from which you can "select" here.  I wonder if
some HTML link is missing in the sentence (i.e., clicking a word
leading to a page that lists what you can select from), or it has
always been like this.

Later in the same document, I see

    How to find other ideas for microprojects

    First check the specific page(s) or information about Git
    microprojects related to your program that should have been
    published on this site or on the GSoC or Outreachy site. But then
    still read on everything below!

which is much more realistic, as long as the "specific page(s)" are
well curated (which I have no idea myself, as I have never been in
the mentoring pool).  Naomi, have you checked and found such a page
on Outreachy site?

Then it goes on to suggest finding a bug report, but I tend to think
that fixing them is way oversized to be a good microproject.


And finally it gives a casual mention of good+first+issue, which is
probably the closest to what _should_ be listed as the first place
to try (sorry, I however do not know how well the list is curated,
either, but from a cursory look it looks legit).

https://github.com/gitgitgadget/git/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22

There also is a mention of #leftoverbits in the document, but by its
nature, they can easily become stale or irrelevant, and they tend to
be more real issues, and I would expect them to be unnecessarily
harder than what dip-your-toe-in-the-water-and-say-hello
microprojects need to be.

Re: How To Pick And Work On A Microproject

[Christian Couder]

On Fri, Oct 6, 2023 at 12:42 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Naomi Ibe <naomi.ibeh69@gmail.com> writes:
>
> > "Select a microproject and check that it has not yet been taken or
> > discussed by searching the mailing list. Public Inbox is your friend."
>
> Yeah, that is VERY unfriendly.  There is no mention on the pool of
> microproject ideas from which you can "select" here.  I wonder if
> some HTML link is missing in the sentence (i.e., clicking a word
> leading to a page that lists what you can select from), or it has
> always been like this.

This sentence has been like that for a long time. I have just improved
it to the following:

"* Select a microproject and check that it has not yet been taken or
  discussed by searching the mailing list. Please read all the
  sections below related to finding or selecting a microproject."

I have also made it clearer that the list these sentences are in is a
"Summary of the steps needed to complete a microproject" by adding a
section with that title.

> Later in the same document, I see
>
>     How to find other ideas for microprojects
>
>     First check the specific page(s) or information about Git
>     microprojects related to your program that should have been
>     published on this site or on the GSoC or Outreachy site. But then
>     still read on everything below!
>
> which is much more realistic, as long as the "specific page(s)" are
> well curated (which I have no idea myself, as I have never been in
> the mentoring pool).  Naomi, have you checked and found such a page
> on Outreachy site?

There is no such page as I haven't taken the time to write one. But I
have added the following paragraph just below the above one:

"It’s also possible that we haven’t taken the time to put up a page
listing microprojects ideas for your program. The pages we used to
create for that were named “XXXX Applicant Microprojects” where XXXX
is the program name and a date, for example “SoC 2016 Applicant
Microprojects” for the GSoC in 2016, or “Outreachy Winter 2021-2022
Applicant Microprojects” for Outreachy in 2021-2022. See the following
directory to find these old pages that might still be useful:

https://git.github.io/Historical-SoC-Outreachy/"

I am not sure how others feel about this, but I think it would be
better in the future to not have to prepare such pages, and to just
have a section with a number of examples of good microprojects on this
https://git.github.io/General-Microproject-Information/ page. It will
be easier to update this section when we know about other good ideas
or better ideas, or when we want to remove an idea that we don't
consider good anymore, or just update an idea.

> Then it goes on to suggest finding a bug report, but I tend to think
> that fixing them is way oversized to be a good microproject.

I agree that it's oversized for most bugs. I have just added the
following paragraph at the end of this "Searching for bug reports"
subsection:

"Also some bugs are difficult to understand and require too much or
too difficult work for a microproject, so don’t spend too much time on
them if it appears that they might not be simple to fix, and don’t
hesitate to ask on the mailing list if they are a good microproject."

> And finally it gives a casual mention of good+first+issue, which is
> probably the closest to what _should_ be listed as the first place
> to try (sorry, I however do not know how well the list is curated,
> either, but from a cursory look it looks legit).
>
> https://github.com/gitgitgadget/git/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22
>
> There also is a mention of #leftoverbits in the document, but by its
> nature, they can easily become stale or irrelevant, and they tend to
> be more real issues, and I would expect them to be unnecessarily
> harder than what dip-your-toe-in-the-water-and-say-hello
> microprojects need to be.

I have just added the following at the end of the subsection about
#leftoverbits:

"As for bugs, and many things really, you can also ask if you are not
sure it's simple enough to fix."

Thanks for reviewing the doc!

Re: How To Pick And Work On A Microproject

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> I am not sure how others feel about this, but I think it would be
> better in the future to not have to prepare such pages, and to just
> have a section with a number of examples of good microprojects on this
> https://git.github.io/General-Microproject-Information/ page. It will
> be easier to update this section when we know about other good ideas
> or better ideas, or when we want to remove an idea that we don't
> consider good anymore, or just update an idea.

If we have curated one-stop shop for microproject candidates to make
it easy to find them, it would be a vast improvement over the status
quo.  The easier for us to update the contents of the list, the
better for participants.  Having only one place that we need to look
at is one way to do so, and the general microproject information
page would be the best place to host it.  I like it.

>> Then it goes on to suggest finding a bug report, but I tend to think
>> that fixing them is way oversized to be a good microproject.
>
> I agree that it's oversized for most bugs. I have just added the
> following paragraph at the end of this "Searching for bug reports"
> subsection:
>
> "Also some bugs are difficult to understand and require too much or
> too difficult work for a microproject, so don’t spend too much time on
> them if it appears that they might not be simple to fix, and don’t
> hesitate to ask on the mailing list if they are a good microproject."

Would that be better, or would it be simpler to gut the whole
paragraph about bug reports?  This is "how to pick a microproject",
not "how to pick your main project to work on during your mentoring
program".

Unlike #leftoverbits that sometimes cover trivial but boring style
normalization and easy refactoring of code into helper functions, I
have never seen a bug report on the list that may make a good
microproject.  If we were to add a curated list of microproject idea
on the general microproject information page, it probably is better
to remove these mentions of bugreports and #leftoverbits, so that
readers will not get distracted.  "Don't hesitate to ask" so that
they may try to tackle more challenging one, if they wish, is a good
thing to say nevertheless.

Thanks.