Re: How To Pick And Work On A Microproject

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 6, 2023, 19:03 UTC
Message-ID: <xmqq1qe7a806.fsf@gitster.g>
In-Reply-To: <CAP8UFD1cd5YZqAxYbYUMNkAYJLLGjBpNe_NK5nVq3eLxxSDzEQ@mail.gmail.com>

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

Show 7 quoted lines

> 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.

Show 11 quoted lines

>> 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.