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
next prev parent 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