Re: A starter task

On 9/16/24 10:35, sia kc wrote:
> 
> 
> On Mon, Sep 16, 2024 at 11:28 AM Tomas Vondra <tomas@vondra.me
> <mailto:tomas@vondra.me>> wrote:
> 
>     On 9/16/24 00:17, sia kc wrote:
>     > I have a bad experience. I picked up a task from MariaDB backlog,
>     > explained in their chat rooms that I started doing that. After it was
>     > done which was a SQL command which MySQL already supported to restart
>     > server instance with SQL, they started rethinking the validity of the
>     > feature for the MariaDB. So the task got suspended.
>     >
> 
>     Unfortunately this can happen here too, to some extent. Sometimes it's
>     not obvious how complex the patch will be, the feature may conflict with
>     another feature in some unexpected way, etc. It's not like we have a
>     100% validated and agreed design somewhere.
> 
> 
> 
>     This is why my advice is to pick a patch the contributor is personally
>     interested in. It puts him/her in a better position to advocate for the
>     feature, decide what trade offs are more appropriate, etc.
> 
> By picking a patch I assume you mean picking an already done task and
> seeing for example how I would have done it, right?
> 

I mean both the patch you'd review and the patch/feature you'd be
writing yourself. My experience is that when a person is genuinely
interested in a topic, that makes it easier to reason about approaches,
trade offs, and stick with the patch even if it doesn't go smoothly.

It's a bit similar to a homework. I always absolutely hated homework
done only for the sake of a homework, and done the absolutely bare
minimum. But if it was something useful/interesting, I'd spend hours
perfecting it. Patches are similar, IMO.

If you pick a patch that's useful for you (e.g. the feature would make
your job easier), that's a huge advantage IMO.


regards

-- 
Tomas Vondra