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