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.
Junio C Hamano wrote:
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):
[...]
- 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
[...]
- 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.
I also should (reluctantly) mention that the Debian bug tracker has
been accepting bugs from outsiders and provides a service like this.
Caveats:
- it only tracks bugs that affect Debian (usually meaning
platform-independent bugs). Occasionally bugs from Windows users
have been reported there and it's been okay.
- the interface might seem quirky if you're not used to it.
Documentation is at http://www.debian.org/Bugs/
- no guarantee of a quick response. When there is a response,
usually it is "here are some thoughts; now let's take this to
git@vger.kernel.org".
- if the bugtracker gets swamped with reports from outside without
manpower to match, the policy re bugs from outside Debian might
change.
Bug listing: [1].
To subscribe to receive bug reports by email: [2].
Thoughts welcome, as always.
Jonathan
[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=git;include=tags:upstream;exclude=tags:fixed-upstream;exclude=tags:moreinfo;exclude=severity:wishlist
[2] http://www.debian.org/doc/manuals/developers-reference/resources.html#pts-commands
Summary: an email to pts@qa.debian.org whose body contains the two
lines "subscribe git", "keyword git = bts" would do the trick.
On Wed, Sep 14, 2011 at 11:29:28AM -0700, Junio C Hamano wrote:
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):
Is there such a thing as enough coders? :)
Two things that got me started on git, and that I think are still
relevant today:
1. Scratch your own itch. Surely git doesn't do something that you
wish it did. Or did it faster. Or whatever. Try to dig up past
discussions on the list to make sure you're not doing something
that has already been tried and rejected, and then start hacking.
Your patches may be terrible at first, but I think there are people
willing to guide you if you actually have running code.
2. Read the list. People will report bugs. Try reproducing them,
bisecting them, creating minimal test cases, narrowing the issues
down to certain configurations or a certain bit of code, etc.
Sometimes that will lead you to propose a solution. Sometimes
you'll just add to the discussion, and then somebody with more
familiarity can pick up the topic from there. But you'll have
helped them by doing some of the work, and you'll have learned more
about how git works.
-Peff