> 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 <armin...@gmail.com>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 < > johnson.tom+code4...@gmail.com > > 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 <jstirna...@kumc.edu > > >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 [CODE4LIB@LISTSERV.ND.EDU] on behalf of Karen > > > Coyle [li...@kcoyle.net] > > > Sent: Wednesday, February 20, 2013 10:42 AM > > > To: CODE4LIB@LISTSERV.ND.EDU > > > 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 > > > kco...@kcoyle.net http://kcoyle.net > > > ph: 1-510-540-7596 > > > m: 1-510-435-8234 > > > skype: kcoylenet > > > > > >