Ah, my bad.

> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Karen Coyle
> Sent: Wednesday, February 20, 2013 1:15 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)
> 
> WE're talking about wordpress, not github.
> 
> kc
> 
> On 2/20/13 9:56 AM, Johnston, Leslie wrote:
> > It's technically breaking GitHub's terms of service to have multiple
> individuals sharing a single account.
> >
> > Leslie
> >
> >> -----Original Message-----
> >> From: Code for Libraries [mailto:[log in to unmask]] On Behalf
> >> Of Karen Coyle
> >> Sent: Wednesday, February 20, 2013 12:07 PM
> >> To: [log in to unmask]
> >> Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)
> >>
> >> Sure. Although the question was more: how can we make it easy to
> have
> >> a bunch of accounts? Or should we have a c4l account that we share
> >> (and monitor for spam)? I think anything wysiwyg-y and familiar
> >> (wordpress certainly meets those criteria) would be fine. There does
> >> seem to be a lot of familiarity with Wordpress in the group.
> >>
> >> kc
> >>
> >>
> >> On 2/20/13 8:45 AM, Ethan Gruber wrote:
> >>> Wordpress?
> >>>
> >>>
> >>> On Wed, Feb 20, 2013 at 11:42 AM, Karen Coyle <[log in to unmask]>
> >> 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?
> >>>>
> >>>> 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<https://git
> >>>>> hub.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<h
> >>>>> ttps://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<https://gith
> >>>>> ub.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/<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
> >>>>
> >> --
> >> Karen Coyle
> >> [log in to unmask] http://kcoyle.net
> >> ph: 1-510-540-7596
> >> m: 1-510-435-8234
> >> skype: kcoylenet
> 
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet