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