lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ’Pond Jobs & Their Descriptions


From: David Kastrup
Subject: Re: ’Pond Jobs & Their Descriptions
Date: Thu, 06 Feb 2020 15:00:39 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Jonas Hahnfeld <address@hidden> writes:

> Am Mittwoch, den 05.02.2020, 21:24 -0500 schrieb Kieren MacMillan:
>> Hi again, Graham:
>> 
>> More concretely… Where can I go, in the CG or elsewhere, to find
>> something that looks like this:
>> 
>> Job: Patch Formatter
>> Tasks: Ensure that a submitted patch conforms to the Lilypond code
>> standards (found <here> and <here> and <here>).
>> Requirements: a text editor; working knowledge of the programming
>> language(s) used in a given patch (possibilities: C++, Scheme,
>> python).
>> Estimated Time Commitment: 5 minutes (per average patch), currently
>> an average of 7 patches per week
>> References & Links: <Lilypond code style guide here>, <good
>> auto-formatting tools here>, etc.
>> Receives From: Patch Submitter or Patch Reviewer
>> Passes To: Patch Reviewer
>
> My thoughts: Formalizing to that degree hurts an open source project
> instead of helping. It gives new contributors a lot more to understand
> to even start and decreases efficiency for developers, as every micro-
> managing does in day jobs. Personally I don't want to see tens of jobs
> that I all have to memorize in order to contribute.

The way I read the request I thought is was more about having an
organizational document, not for the sake of getting a submission in,
but rather for understanding where help in improving the processes (by
code or manual labor) would be appreciated, and what kind of expertise
this would entail.

I may have been completely misunderstanding Kieren here, but that might
be of interest anyway.

> I'm open to reconsider the current description of jobs, adapt if
> necessary, and add new jobs if really needed - but certainly not a
> "Patch Formatter", that's part of the review process which is no job,
> every developer should participate.

Well, we don't really point out helpful resources for that a lot, do we?

> Jonas


-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]