From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Wong Subject: Re: OT: mail-based interfaces and web-based interfaces (Re: Extract Date: Thu, 26 Jul 2012 03:10:48 +0000 Message-ID: <20120726031048.GA8034@dcvr.yhbt.net> References: <5004B772.3090806@pobox.com> <20120717174446.GA14244@burratino> <5005F139.8050205@pobox.com> <20120717233125.GF25325@burratino> <7vy5mhwrdl.fsf@alter.siamese.dyndns.org> <500F23E4.9090306@pobox.com> <20120725025507.GB13236@dcvr.yhbt.net> <500F860E.5010909@pobox.com> <20120725234838.GA16020@dcvr.yhbt.net> <5010AC7B.6020805@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Junio C Hamano , Jonathan Nieder , git@vger.kernel.org, robbat2@gentoo.org, Ben Walton To: Michael G Schwern X-From: git-owner@vger.kernel.org Thu Jul 26 05:11:23 2012 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SuETy-00072d-7W for gcvg-git-2@plane.gmane.org; Thu, 26 Jul 2012 05:11:22 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751313Ab2GZDKv (ORCPT ); Wed, 25 Jul 2012 23:10:51 -0400 Received: from dcvr.yhbt.net ([64.71.152.64]:42467 "EHLO dcvr.yhbt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750770Ab2GZDKu (ORCPT ); Wed, 25 Jul 2012 23:10:50 -0400 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 2650A1F5B2; Thu, 26 Jul 2012 03:10:49 +0000 (UTC) Content-Disposition: inline In-Reply-To: <5010AC7B.6020805@pobox.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Michael G Schwern wrote: > On 2012.7.25 4:48 PM, Eric Wong wrote: > > We need to use something. Right now our choice of mailer is the best > > choice for _existing_ contributors. > > I believe this entire discussion can be reduced to that right there. > > If your process is optimized for existing contributors, it will work well for > existing contributors, who will want to optimize it for themselves. Repeat. > If the main way you evaluate your process is asking "is this more convenient > for me" then you're probably in that spiral. > > This creates a process very well tuned to the existing contributors, and its > very convenient for them. But the consequence is it becomes more and more > work for a new contributor to join. The process is _not_ a lot of work. At least no more than any other project: observe the regulars -> imitate the regulars Many/most regular git contributors are not Linux kernel developers, yet were able to quickly able to get up-to-speed with git. AFAIK, the Linux kernel gets plenty of new contributors every year, too. > Before talking about anything else, the existing contributors have to ask > themselves a simple question: Do we care about getting new contributors? Yes, if contributors are willing to learn/respect existing conventions. We do take time to help new contributors out :) For me, it's certainly "no" if there's any endorsement of non-Free Software or centralized/commercial services involved. > The answer can be "no" ("yes, but not if I'm inconvenienced" is a no). Maybe > you're happy with the people you've got. But there's no point in getting into > detail until that's settled.