Print

Print


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