> but it would be difficult to replace the social network around the
projects.

Especially difficult now that GitHub is where the community is. It's
technically possible to build a social web that works on a decentralized
basis, but it may no longer be culturally possible. Platforms are hard to
get down from.

On Wed, Feb 20, 2013 at 11:12 AM, Benjamin Armintor <[log in to unmask]>wrote:

> You are definitely insulated from loss of material by the distributed
> character of git, but it would be difficult to replace the social network
> around the projects. You really see this when you work with a non-Github
> git repository: Getting a copy of it is trivial, but you have no mechanism
> for alerting the original repository (much less its network) of potentially
> valuable changes. Of course, there's the old-fashioned splash-pages and
> contact emails, but the relative triviality of advertising changes to a
> Github repository (and accepting them, for that matter) is pretty
> groundbreaking.
>
> - Ben
>
>
> On Wed, Feb 20, 2013 at 2:04 PM, Tom Johnson <
> [log in to unmask]
> > wrote:
>
> > > But while I get the argument for utility, there does seem to be
> > barrier-to-entry there for someone just wanting to submit a poem.
> >
> > The original suggestion wasn't about utility, but about modes of writing.
> > Git repositories would make for poems which are easily shared, copied,
> > "forked", and merged back together. I'm interested in the relationship
> this
> > has to the idea of an "oral tradition". Especially given that a "git
> > poetry" tradition would record its own history in the medium.
> >
> > I agree that wordpress is much more accessible. It seems obvious to me
> that
> > we could post poems where we see fit and aggregate them. Written and oral
> > is even more accessible than that. It seems obvious to me that we could
> > write down and/or recite poems, pass them around, and commit them to
> > memory. I think we should do all these things--and maybe play around with
> > git, too.
> >
> > For me, the important take away from this discussion is that git art
> > shouldn't be the dominant form of expression or the raison d'etre for the
> > 'nerd poetry' idea.
> >
> > As an aside: I share the concerns about GitHub. I resisted joining for
> > years because of exactly this issue. If Facebook is a man-in-the-middle
> > exploit on social interaction, then surely GitHub is the same on Free
> > Software development. I thought the FOSS community would be better served
> > if we all put up our git repositories in our own ways, and tried to build
> > tools for collaboration. As it turns out, GitHub has done wonders for
> code
> > sharing and collaborative development and the company has been good to
> us,
> > which is why I'm there now. I still worry about ways the our platform
> > dependence could go badly. Luckily, the risk is mitigated by gits
> > distributed and portable nature.
> >
> > - Tom
> >
> >
> > On Wed, Feb 20, 2013 at 10:20 AM, Jason Stirnaman <[log in to unmask]
> > >wrote:
> >
> > > Another option might be to set it up like the Planet. Where individuals
> > > just post their poetry to their own blogs, Tumblrs, etc., tag them, and
> > > have $PLANET_NERD_POETS aggregate them.
> > >
> > > Git and Github are great. But while I get the argument for utility,
> there
> > > does seem to be barrier-to-entry there for someone just wanting to
> > submit a
> > > poem.
> > >
> > > Jason
> > >
> > > Jason Stirnaman
> > > Digital Projects Librarian
> > > A.R. Dykes Library
> > > University of Kansas Medical Center
> > > 913-588-7319
> > >
> > > ________________________________________
> > > From: Code for Libraries [[log in to unmask]] on behalf of Karen
> > > Coyle [[log in to unmask]]
> > > Sent: Wednesday, February 20, 2013 10:42 AM
> > > To: [log in to unmask]
> > > Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)
> > >
> > > Shaun, you cannot decide whether github is a barrier to entry FOR ME
> (or
> > > anyone else), any more than you can decide whether or not my foot
> hurts.
> > > I'm telling you github is NOT what I want to use. Period.
> > >
> > > I'm actually thinking that a blog format would be nice. It could be
> > > pretty (poetry and beauty go together). Poems tend to be short, so
> > > they'd make a nice blog post. They could appear in the Planet blog
> roll.
> > > They could be coded by author and topic. There could be comments! Even
> > > poems as comments! The only down-side is managing users. Anyone have
> > > ideas on that?
> > >
> > > kc
> > >
> > >
> > > On 2/20/13 8:20 AM, Shaun Ellis wrote:
> > > > > (As a general rule, for every programmer who prefers tool A, and
> says
> > > > > that everybody should use it, there’s a programmer who disparages
> > tool
> > > > > A, and advocates tool B. So take what we say with a grain of salt!)
> > > >
> > > > It doesn't matter what tools you use, as long as you and your team
> are
> > > > able to participate easily, if you want to.  But if you want to
> > > > attract  contributions from a given development community, then
> > > > choices should be balanced between the preferences of that community
> > > > and what best serve the project.
> > > >
> > > > From what I've been hearing, I think there is a lot of confusion
> about
> > > > GitHub.  Heck, I am constantly learning about new GitHub features,
> > > > APIs, and best practices myself. But I find it to be an incredibly
> > > > powerful platform for moving open source, distributed software
> > > > development forward.  I am not telling anyone to use GitHub if they
> > > > don't want to, but I want to dispel a few myths I've heard recently:
> > > >
> > > > ------------
> > > >
> > > > * Myth #1 : GitHub creates a barrier to entry.
> > > > * "To contribute to a project on GitHub, you need to use the
> > > > command-line. It's not for non-coders."
> > > >
> > > > GitHub != git.  While GitHub was initially built for publishing and
> > > > sharing code via integration with git, all GitHub functionality can
> be
> > > > performed directly through the web gui.  In fact, GitHub can even be
> > > > used as your sole coding environment. There are other tools in the
> > > > "eco-system" that allow non-coders to contribute documentation, issue
> > > > reporting, and more to a project.
> > > >
> > > > ------------
> > > >
> > > > * Myth #2 : GitHub is for sharing/publishing code.
> > > > * "I would be fun to have a wiki for more durable poetry (github
> > > > unfortunately would be a barrier to many)."
> > > >
> > > > GitHub can be used to collaborate on and publish other types of
> > > > content as well.  For example, GitHub has a great wiki component* (as
> > > > well as a website component).  In a number of ways, has less of a
> > > > "barrier to entry" than our Code4Lib wiki.
> > > >
> > > > While the path of least resistance requires a "repository" to have a
> > > > wiki, public repos cost nothing and can consist of a simple "README"
> > > > file.  The wiki can be locked down to a team, or it can be writable
> by
> > > > anyone with a github account.  You don't need to do anything via
> > > > command-line, don't need to understand "git-flow", and you don't even
> > > > need to learn wiki markup to write content. All you need is an
> account
> > > > and something to say, just like any wiki. Log in, go to the
> > > > anti-harassment policy wiki, and see for yourself:
> > > > https://github.com/code4lib/antiharassment-policy/wiki
> > > >
> > > > * The github wiki even has an API (via Gollum) that you can use to
> > > > retrieve raw or formatted wiki content, write new content, and
> collect
> > > > various meta data about the wiki as a whole:
> > > > https://github.com/code4lib/antiharassment-policy/wiki/_access
> > > >
> > > > ------------
> > > >
> > > > * Myth #3 : GitHub is person-centric.
> > > > > "(And as a further aside, there’s plenty to dislike about github as
> > > > > well, from it’s person-centric view of projects (rather than
> > > > > team-centric)..."
> > > >
> > > > Untrue. GitHub is very team centered when using organizational
> > > > accounts, which formalize authorization controls for projects, among
> > > > other things: https://github.com/blog/674-introducing-organizations
> > > >
> > > > ------------
> > > >
> > > > * Myth #4 : GitHub is monopolizing open source software development.
> > > > > "... to its unfortunate centralizing of so much free/open
> > > > > source software on one platform.)"
> > > >
> > > > Convergence is not always a bad thing. GitHub provides a great, free
> > > > service with lots of helpful collaboration tools beyond version
> > > > control.  It's natural that people would flock there, despite having
> > > > lots of other options.
> > > >
> > > > ------------
> > > >
> > > > -Shaun
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 2/19/13 5:35 PM, Erik Hetzner wrote:
> > > >> At Sat, 16 Feb 2013 06:42:04 -0800,
> > > >> Karen Coyle wrote:
> > > >>>
> > > >>> gitHub may have excellent startup documentation, but that startup
> > > >>> documentation describes git in programming terms mainly using *nx
> > > >>> commands. If you have never had to use a version control system
> > > >>> (e.g. if
> > > >>> you do not write code, especially in a shared environment), "clone"
> > > >>> "push" "pull" are very poorly described. The documentation is all
> in
> > > >>> terms of *nx commands. Honestly, anything where this is in the
> > > >>> documentation:
> > > >>>
> > > >>> On Windows systems, Git looks for the |.gitconfig| file in the
> > |$HOME|
> > > >>> directory (|%USERPROFILE%| in Windows’ environment), which is
> > > >>> |C:\Documents and Settings\$USER| or |C:\Users\$USER| for most
> > people,
> > > >>> depending on version (|$USER| is |%USERNAME%| in Windows’
> > environment).
> > > >>>
> > > >>> is not going to work for anyone who doesn't work in Windows at the
> > > >>> command line.
> > > >>>
> > > >>> No, git is NOT for non-coders.
> > > >>
> > > >> For what it’s worth, this programmer finds git’s interface pretty
> > > >> terrible. I prefer mercurial (hg), but I don’t know if it’s any
> better
> > > >> for people who aren’t familar with a command line.
> > > >>
> > > >>    http://mercurial.selenic.com/guide/
> > > >>
> > > >> (As a general rule, for every programmer who prefers tool A, and
> says
> > > >> that everybody should use it, there’s a programmer who disparages
> tool
> > > >> A, and advocates tool B. So take what we say with a grain of salt!)
> > > >>
> > > >> (And as a further aside, there’s plenty to dislike about github as
> > > >> well, from it’s person-centric view of projects (rather than
> > > >> team-centric) to its unfortunate centralizing of so much free/open
> > > >> source software on one platform.)
> > > >>
> > > >> best, Erik
> > > >>
> > > >>
> > > >>
> > > >> Sent from my free software system <http://fsf.org/>.
> > > >>
> > >
> > > --
> > > Karen Coyle
> > > [log in to unmask] http://kcoyle.net
> > > ph: 1-510-540-7596
> > > m: 1-510-435-8234
> > > skype: kcoylenet
> > >
> >
>