git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Christian Couder <chriscool@tuxfamily.org>
Cc: git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>,
	Junio C Hamano <gitster@pobox.com>,
	Scott Chacon <schacon@gmail.com>,
	Sam Vilain <sam.vilain@catalyst.net.nz>,
	Petr Baudis <pasky@suse.cz>
Subject: Re: GitTogether topics status (4th of October)
Date: Mon, 6 Oct 2008 23:15:09 -0400	[thread overview]
Message-ID: <20081007031509.GA6031@coredump.intra.peff.net> (raw)
In-Reply-To: <200810041816.41026.chriscool@tuxfamily.org>

On Sat, Oct 04, 2008 at 06:16:40PM +0200, Christian Couder wrote:

> 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

  reply	other threads:[~2008-10-07  3:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-04 16:16 GitTogether topics status (4th of October) Christian Couder
2008-10-07  3:15 ` Jeff King [this message]
2008-10-07  3:46   ` Nicolas Pitre
2008-10-07 14:38     ` Shawn O. Pearce
2008-10-07 14:46   ` Shawn O. Pearce
2008-10-17 19:18 ` René Scharfe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081007031509.GA6031@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pasky@suse.cz \
    --cc=sam.vilain@catalyst.net.nz \
    --cc=schacon@gmail.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).