caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Markus Mottl <markus.mottl@gmail.com>
To: Gabriel Scherer <gabriel.scherer@gmail.com>
Cc: "Richard W.M. Jones" <rich@annexia.org>,
	Yotam Barnoy <yotambarnoy@gmail.com>,
	 Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Moving ocaml to github (as well)
Date: Sun, 22 Dec 2013 17:36:27 -0500	[thread overview]
Message-ID: <CAP_800ryhVN3q5=nb53nTOfCDBVTE=7cqzxpDp-s18=3YxUBGA@mail.gmail.com> (raw)
In-Reply-To: <CAPFanBEoP66D4ZxpokiUibdFZ=qu-HcuaV0O-4Tk0-iHgih_MQ@mail.gmail.com>

On Sun, Dec 22, 2013 at 11:41 AM, Gabriel Scherer
<gabriel.scherer@gmail.com> wrote:
> I understand that github provides an homogeneous experience so that users
> don't have to wonder about what the workflow is, and that OCaml users may
> need more explicit information about how to contribute (we can work on
> that). I'm a bit surprised that an expert user that is a long-time
> contributor on the bugtracker, such as Markus, would perceive a difference
> in difficulty/welcome-ness here.

I think people generally underestimate by how much lower contribution
hurdles or "better user experience" can improve adoption rates.  The
OPAM vs Godi story should act as a reminder for that.  It's not that
Godi couldn't do what OPAM does, in fact, I think it could do pretty
much all of what users and developers needed.  It's just that it
required developers and users to jump through a few more hoops to
achieve the intended results, enough to prevent it from gaining such
quick and wide adoption.

Some of the issues may be more perceived than real.  E.g. a
contributor might fear that their patch is more likely to be ignored
in a bug tracker, maybe because it clashes with newer changes due to
the lack of revision control.  But at the end of the day the only
thing that matters is whether a developer is willing to make a
contribution.  Your milage on larger, more complex projects may vary,
but when I translated/switched my projects from CVS to Mercurial on
Bitbucket (Github surely would be similar), the effort was so
laughably small, literally a few minutes per project, I'd find it hard
to believe that workarounds or improved documentation for better
interaction through SVN could possibly be worth it.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

  reply	other threads:[~2013-12-22 22:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-20 19:05 Yotam Barnoy
2013-12-21 10:00 ` Gabriel Scherer
2013-12-22 14:03   ` Richard W.M. Jones
2013-12-22 14:07     ` Richard W.M. Jones
2013-12-22 15:53       ` Markus Mottl
2013-12-22 16:41         ` Gabriel Scherer
2013-12-22 22:36           ` Markus Mottl [this message]
2013-12-23  6:41           ` Martin Jambon
2013-12-22 15:11     ` Daniel Bünzli
2013-12-22 22:55     ` Ashish Agarwal
2013-12-23  2:42       ` Yotam Barnoy

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='CAP_800ryhVN3q5=nb53nTOfCDBVTE=7cqzxpDp-s18=3YxUBGA@mail.gmail.com' \
    --to=markus.mottl@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=gabriel.scherer@gmail.com \
    --cc=rich@annexia.org \
    --cc=yotambarnoy@gmail.com \
    /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).