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