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