[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue difficulty tags (was: Manipulating instrument names and staff grou
Jean Abou Samra
Issue difficulty tags (was: Manipulating instrument names and staff group names)
Sun, 7 Nov 2021 20:37:20 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1
Le 07/11/2021 à 17:07, Kieren MacMillan a écrit :
Thanks to Lukas and Jean, I’ve got a working LilyDev environment *and* have
successfully done the GitLab branch/push/delete/etc. thing. In other words: For
the first time in almost 20 years of Pond-ing, I’m ready to actively contribute
code directly to the codebase!!
So… first bit of business, carried over from a -user thread:
From: Jean Abou Samra <firstname.lastname@example.org <mailto:email@example.com>>
Subject: Re: Manipulating instrument names and staff group names
Date: November 6, 2021 at 4:08:15 PM EDT
To: Kieren MacMillan <firstname.lastname@example.org
Cc: Lilypond-User Mailing List <email@example.com
2. Is there a tag/label on GitLab which identifies all and only those issues
which don’t (or at least shouldn’t likely) require any C++ work?
There isn't. We had Frog in the past (good for beginners,
not language-specific), but it was practically unused and
the issues tagged were not actually so easy. Feel free to
propose something on the devel list though.
My goal is to be able to search the issues by language(s) required [i.e.,
filter out anything that requires more than Scheme], sort the list by
difficulty [ascending], and start hacking away from the top. In order to do
this, I imagine we’d need tags/labels for both “language(s)” and “difficulty”.
I don’t want to clutter up the label-space… but I offer that adding something
would help beginners like me to feel comfortable jumping in.
1. “Language(s)”. While I would love it to be one tag per language involved
(C++, Scheme, Python) — which would allow really granular searching/filtering —
that might be overkill for everyone else. Maybe just one tag (e.g.,
“Scripting”) for things that don’t require recompilation?
2. “Difficulty”. Any multi-level (and thus multi-tag) system would be fine, as
long as it’s at least three levels (e.g., Easy, Medium, Hard); optimal would
be, say, a scale from 1 to 10 (e.g., Difficulty-1, Difficulty-2, etc.).
The problem for both of these is that often,
investigating what the bug is and how it
might be fixed is the main part of the work.
So if you have a good idea of what language
is required and how hard it is, you're
close enough to a fix that it's worth it
to actually prepare the fix.
In other words: it's easy to see if an issue
is easy, and it's hard to see if an non-easy
issue is medium or hard. Consequently, I don't
think we can do much better than tagging easy
issues. We're solving open problems, not
Add that a contribution need not be linked to
an issue. It can be a code cleanup, adding your
secret pet feature, restructuring internals (that
one is not for beginners), adding a predefined
command for something common, ...
As a first “Frog Task”, I’d be happy to do a pass through all ~1,000 currently
open issues and do my best to apply at least the right Language tag(s); I could
also take a guess at the Difficulty level (but might, in many cases, be way off
to start!) which more experienced developers could re-tag as necessary.
The obvious alternative to all of this is for me to have an assigned “mentor”,
who would farm out “the right next task”, taking into account my skill set, the
language(s) and difficulty of the issue, etc. But I don’t want to add ongoing
work to anyone else’s plate, so I figured the suggestion above might be
Would that motivate you? We have different
personalities... I wouldn't have liked a
(virtual, past) mentor telling me what to
work on next: rather, I started with what
I was interested in/competent enough with.
And I continue like that -- just like
If you would like specific proposals of
issues to work with, I have no problem
bringing them (others should feel free
to propose themselves too). But I would
spontaneously expect it to come in the
other way: ask about what you have in
mind, and any sort of mentor can tell you
if it sounds feasible for a beginner.
Designing mentorship programs is hard :-)