 |
 |
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