On Feb 20, 2013, at 11:42 AM, Karen Coyle <li...@kcoyle.net> wrote: > 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?
Of course, these aren't mutually exclusive: http://octopress.org/ -Ross. > > 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
