Re: Helping on Git development

Andrew Ardill [off-list ref] writes:

On 14 September 2011 13:05, Eduardo D'Avila [off-list ref] wrote:

quoted

Hi,

I have being using Git for some time now and I am very satisfied with it.
Now I'm considering giving back by helping on its development.
Is there any bug listing which I can check if there is some point I can help?
Any suggestions on other ways to help are also welcomed. :-)

Hi Eduardo, as stated in the README,

The messages titled "A note from the maintainer", "What's in git.git
(stable)" and "What's cooking in git.git (topics)" and the discussion
following them on the mailing list give a good reference for project
status, development direction and remaining tasks.

Additionally, I think the README should include something like

If you are looking to contribute to the project, a good place to start
is http://git-blame.blogspot.com/p/note-from-maintainer.html and in
Documentation/howto/maintain-git.txt

I am moderately averse to hardcoding that URL that is guaranteed not to
survive the maintainer change in our README file. The howto/maintain-git
document mentions the periodical "A note from the maintainer" posting to
the list that has the same text, which is a more appropriate reference.

As to contributing to the project, right now, I think we have enough
people who want to write code and documentation for Git, but what we lack
are bandwidth to (this is not meant to be an exhaustive list):

 - review the patches on the list and help perfecting them;

 - distilling random wishes from the end user community while winnowing
   chaffs that are unrealistic or do not fit well with the grand scheme of
   things, to come up with a concrete proposal and a patch series to move
   the discussions forward in a productive way;

 - "on boarding" new contributors, helping them to become a useful member
   of the community, teaching how to write a good bug report and how to
   sell a new feature (i.e. "the perfect patch");

 - dig list archives to point people at age-old discussions to non-issues
   that have long been resolved to squelch noise; and

 - remind original submitter, people who were involved in the discussion,
   and people who should have been involved but who weren't, of a worthy
   but stalled topics from time to time.

The first two need to come from more experienced folks whose judgement I
can trust (iow, not a newbie task). Others are "project secretary" tasks
that can be helped by anybody who is good at tracking things, perhaps
except for the last one that needs a good taste when judging which topic
is worthy of reminders.