Re: GitTogether topics status (4th of October)
- From
Jeff King <peff@peff.net>
- Date
- Oct 7, 2008, 03:15 UTC
- Message-ID
- <20081007031509.GA6031@coredump.intra.peff.net>
- In-Reply-To
- <200810041816.41026.chriscool@tuxfamily.org>
On Sat, Oct 04, 2008 at 06:16:40PM +0200, Christian Couder wrote:
Show 5 quoted lines
> As can be seen on the GitTogether page on the wiki: > > http://git.or.cz/gitwiki/GitTogether > > the planned speakers/topics changed a lot during the last weeks and are now:
I just added two proposed half-hour meetings, both of which I intend to be a few minutes of me talking followed by group discussion. The topics are:
1. Helping new developers join the git community
This title is a little bit sneaky. I want to talk about not just how
we can get new developers to help improve git, but also how we can
convince them to adopt workflows that make less work for reviewers
and maintainers. It seems like there are some things that we tell
new people over and over about formatting code, formatting patches,
sending patches, etc. Probably the end goal will be improvements to
SubmittingPatches, but maybe putting similar content somewhere more
visible, or maybe even adjusting our workflows a bit. I hope to make it useful for veterans (who may _constructively_
complain about the habits of new developers), and new developers,
who may learn something about contributing. This might overlap a bit with Dscho's "contributing with git" talk
(which I am not sure is a talk about using git to contribute in
general, or using git to contribute to git), but I think the
discussion-like forum will make it different enough to be valuable.2. What needs refactoring?
I occasionally run up against parts of the code that just make my
eyes bleed everytime I touch them. I think we've made significant
progress in maintanability and bug-avoidance with things like the
strbuf library, refactoring of remote and transport handling, etc.
What areas might still benefit from such refactoring?-Peff