Re: Last gasp

Christopher Browne wrote:
> On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt<jay(dot)levitt(at)gmail(dot)com> wrote:
>> Rather than extend the CF app into a trivial-patch workflow app, it might be
>> worth looking at integrating it with github.
>
> There's a reluctance to require a proprietary component that could
> disappear on us without notice.

Excellent point. I was thinking that GitHub's API would allow archival
exporting to counter that, along the lines of "let's take advantage of it
for the next five years until it goes south, and THEN we could write our
own". But I can see how that might not be the best choice for a project that
expects to preserve history for a few decades.

GitHub does offer an "enterprise version" that you can self-host, but it
seems to be priced per-user and intended for solely intranet use.

If the feature set is desirable, though, I wonder if Postgres is big/high
profile enough for them to figure out some sort of better arrangement. They
*love* it when big open-source projects use GitHub as their public repo -
they'll email and blog announcements about it - and if there's interest I'd
be happy to open a conversation with them.

> The existence of git itself is a result of *exactly* that
> circumstance, as Linux kernel developers had gotten dependent on
> BitKeeper, whereupon the owner decided to take his toys home, at which
> point they were left bereft of "their" SCM tool.
> <http://kerneltrap.org/node/4966>

Good history lesson there, with a great outcome.

> I expect that it would be more worthwhile to look into enhancements to
> git workflow such as<http://code.google.com/p/gerrit/> Gerrit. I
> don't know that Gerrit is THE answer, but there are certainly projects
> that have found it of value, and it doesn't have the "oops, it's
> proprietary" problem.

I've looked at it in conjunction with Jenkins CI; it looked nice but was way
too heavy-weight for a four-person startup (what's code review?). It's
probably much more suitable for this sized project.

Gerrit's a full-featured code review app with a tolerable UI; I was thinking
of GitHub more as a great lightweight UI for doc patches and other trivial
patches where you might have lots of casual review and comments but no need
for, say, recording regression tests against each patch version. e.g.:

https://github.com/rails/rails/pull/5730

Also, for doc patches, GitHub has the great advantage of in-place editing
right from the web UI.

Peter mentioned the desire to bring more eyes and hands onto these type of
patches - I think the phrase was "enthusiast power users who wouldn't really
consider themselves hackers." The advantage of GitHub here would be its
(current) widespread adoption; the perceived barrier to entry is far lower
and the workflow is far more obvious than a mailing list, formatting patches
by email, not quite knowing what the process is.

I mention all this not to try to push GitHub specifically, but to say "these
are the types of features that modern, open-source collaborative systems
offer, and could improve community involvement".

From a human- rather than technology-oriented perspective: I was shocked to
find that you folks *WANT* reviews from non-contributors. It was my
assumption as a newcomer that if I don't feel well-versed enough to submit
patches yet, the last thing you'd want me to do was to look over someone
else's patch and say "Yeah, that looks good", any more than I care if my mom
thinks my latest web app is "very nice".

I see now that the "Reviewing a Patch" wiki page explains this, but maybe
this info should be pushed higher into the docs and web site; a "How can I
contribute" page, open calls for reviewers on the non-hackers mailing lists,
things like that. Or maybe just make the wiki page bright red and blink a lot.

Jay