subject:"\[CODE4LIB\] GitHub Myths \(was thanks and poetry\)"

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-22 Thread MJ Ray

Shaun Ellis sha...@princeton.edu
 If you read my email, I don't tell anyone what to use, but simply 
 attempt to clear up some fallacies.  Distributed version control is new 
 to many, and I want to make sure that folks are getting accurate 
 information from this list.

As would I.  I don't think spreading misinformation about the products
of GitHub, Inc, is helping people to get accurate information.

 Unfortunately, this statement is not accurate either:
 
 // There's a sneaky lock-in effect of having one open tool (git hosting) 
 which is fairly easy to move in and out and interoperate with, linked to 
 other closed tools (such as their issues tracker and their non-git pull 
 requests system) which are harder to move out or interoperate. //

Nothing written below points out any inaccuracy.

 GitHub's API allows you to easily export issues if you want to move them 
 somewhere else: http://developer.github.com/v3/issues/

So what's the equivalent command to git clone  to do that, then?
I put harder, not impossible.  You try putting the sausagemeat you get
from that API into any other issue tracker.  Also, that API is only
available to registered users and it's unique as far as I've seen.

 Pull-requests are used by repository hosting platforms to make it easier 
 to suggest patches.  GitHub and BitBucket both use the pattern, 

Well, the pattern comes from the git request-pull tool.  GitHub just
disconnects it from that.

 and I don't understand what you mean by it being a closed tool.
 If you're concerned about barriers to entry, suggesting a patch
 using only git or mercurial can be done, but I wouldn't say it's
 easy.

git send-email and git request-pull are both pretty easy, aren't they?

and what Erik said about open/closed.

 ... and what Devon said.

Which was If you're not willing to provide even your name to make use
of a free service, then I dare say you are erecting your own
barriers.

I'm willing to provide my name.  I'm not willing to provide my full
legal name to them.  They have no need for my full legal name.  Even
if they want to come after me legally, the legal system will either
accept my common alias or convert it for them (I have to tell it both,
for that reason).

Hope that explains,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-22 Thread Jonathan Rochkind

Can you two take your argument somewhere else? This thread is REALLY boring. 

(Am I going to make it worse by posting this? Are people going to start flaming 
me for being intolerant? Would I deserve it? Possibly.  I am willing to take 
that risk in a last ditch hope that the Code4Lib listserv can somehow return to 
having actual discussions of code and technical matters again, instead of being 
like most other non-technical 'library technology' listservs. Unlikely, eh?  
Should we start a Code4LibDiscussingCodeAgain separate listserv? Please don't 
answer any of these questions in this thread, or on this listserv at all, 
really. )

From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of MJ Ray 
[m...@phonecoop.coop]
Sent: Friday, February 22, 2013 3:55 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Shaun Ellis sha...@princeton.edu
 If you read my email, I don't tell anyone what to use, but simply
 attempt to clear up some fallacies.  Distributed version control is new
 to many, and I want to make sure that folks are getting accurate
 information from this list.

As would I.  I don't think spreading misinformation about the products
of GitHub, Inc, is helping people to get accurate information.

 Unfortunately, this statement is not accurate either:

 // There's a sneaky lock-in effect of having one open tool (git hosting)
 which is fairly easy to move in and out and interoperate with, linked to
 other closed tools (such as their issues tracker and their non-git pull
 requests system) which are harder to move out or interoperate. //

Nothing written below points out any inaccuracy.

 GitHub's API allows you to easily export issues if you want to move them
 somewhere else: http://developer.github.com/v3/issues/

So what's the equivalent command to git clone  to do that, then?
I put harder, not impossible.  You try putting the sausagemeat you get
from that API into any other issue tracker.  Also, that API is only
available to registered users and it's unique as far as I've seen.

 Pull-requests are used by repository hosting platforms to make it easier
 to suggest patches.  GitHub and BitBucket both use the pattern,

Well, the pattern comes from the git request-pull tool.  GitHub just
disconnects it from that.

 and I don't understand what you mean by it being a closed tool.
 If you're concerned about barriers to entry, suggesting a patch
 using only git or mercurial can be done, but I wouldn't say it's
 easy.

git send-email and git request-pull are both pretty easy, aren't they?

and what Erik said about open/closed.

 ... and what Devon said.

Which was If you're not willing to provide even your name to make use
of a free service, then I dare say you are erecting your own
barriers.

I'm willing to provide my name.  I'm not willing to provide my full
legal name to them.  They have no need for my full legal name.  Even
if they want to come after me legally, the legal system will either
accept my common alias or convert it for them (I have to tell it both,
for that reason).

Hope that explains,
--
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

[CODE4LIB] IRC and mail was Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-22 Thread Karen Coyle

Well, Jonathan. I believe that you were one of the ones who defended the 
predominance of non-code talk on IRC as community building. So, is the 
listserv for code and IRC for play? (filters, Jonathan, use the 
filters!) Note that many of us eschew the IRC channel because it appears 
to be a gross waste of time. (And note that in our discussion the 
majority of folks who made that statement were men, so don't take it as 
a gender thing.)


One interesting note is that flame wars rarely seem to break out on IRC. 
I suspect it is because the nature of the communication doesn't allow 
one to capture audience attention long enough to make a clear statement 
of one's position. However, that same nature of communication makes it 
hard to get deep about anything. IRC seems to promote chit-chat, even 
though some of that chit-chat is informative.


kc


On 2/22/13 7:18 AM, Jonathan Rochkind wrote:

Can you two take your argument somewhere else? This thread is REALLY boring.

(Am I going to make it worse by posting this? Are people going to start flaming 
me for being intolerant? Would I deserve it? Possibly.  I am willing to take 
that risk in a last ditch hope that the Code4Lib listserv can somehow return to 
having actual discussions of code and technical matters again, instead of being 
like most other non-technical 'library technology' listservs. Unlikely, eh?  
Should we start a Code4LibDiscussingCodeAgain separate listserv? Please don't 
answer any of these questions in this thread, or on this listserv at all, 
really. )

From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of MJ Ray 
[m...@phonecoop.coop]
Sent: Friday, February 22, 2013 3:55 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Shaun Ellis sha...@princeton.edu

If you read my email, I don't tell anyone what to use, but simply
attempt to clear up some fallacies.  Distributed version control is new
to many, and I want to make sure that folks are getting accurate
information from this list.

As would I.  I don't think spreading misinformation about the products
of GitHub, Inc, is helping people to get accurate information.


Unfortunately, this statement is not accurate either:

// There's a sneaky lock-in effect of having one open tool (git hosting)
which is fairly easy to move in and out and interoperate with, linked to
other closed tools (such as their issues tracker and their non-git pull
requests system) which are harder to move out or interoperate. //

Nothing written below points out any inaccuracy.


GitHub's API allows you to easily export issues if you want to move them
somewhere else: http://developer.github.com/v3/issues/

So what's the equivalent command to git clone  to do that, then?
I put harder, not impossible.  You try putting the sausagemeat you get
from that API into any other issue tracker.  Also, that API is only
available to registered users and it's unique as far as I've seen.


Pull-requests are used by repository hosting platforms to make it easier
to suggest patches.  GitHub and BitBucket both use the pattern,

Well, the pattern comes from the git request-pull tool.  GitHub just
disconnects it from that.


and I don't understand what you mean by it being a closed tool.
If you're concerned about barriers to entry, suggesting a patch
using only git or mercurial can be done, but I wouldn't say it's
easy.

git send-email and git request-pull are both pretty easy, aren't they?

and what Erik said about open/closed.


... and what Devon said.

Which was If you're not willing to provide even your name to make use
of a free service, then I dare say you are erecting your own
barriers.

I'm willing to provide my name.  I'm not willing to provide my full
legal name to them.  They have no need for my full legal name.  Even
if they want to come after me legally, the legal system will either
accept my common alias or convert it for them (I have to tell it both,
for that reason).

Hope that explains,
--
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/


--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-21 Thread MJ Ray

Shaun Ellis sha...@princeton.edu
 * Myth #1 : GitHub creates a barrier to entry.

That's a fact, not a myth.  Myself, I won't give GitHub my full legal
name and I suspect there are others who won't.  So, we're not welcome
there and if we lie to register, all our work would be subject to
deletion at an arbitrary future point.

There's a couple of other things in the terms which aren't simple, too.

[...]
 * 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.

Whether or not it's a deliberate monopolising attempt, I don't think
that's the full reason.  It's not only natural effect.  There's a
sneaky lock-in effect of having one open tool (git hosting) which is
fairly easy to move in and out and interoperate with, linked to other
closed tools (such as their issues tracker and their non-git pull
requests system) which are harder to move out or interoperate.

Use github if you like.  Just don't expect everyone to do so.

Hope that explains,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-21 Thread Shaun Ellis

If you read my email, I don't tell anyone what to use, but simply 
attempt to clear up some fallacies.  Distributed version control is new 
to many, and I want to make sure that folks are getting accurate 
information from this list.


Unfortunately, this statement is not accurate either:

// There's a sneaky lock-in effect of having one open tool (git hosting) 
which is fairly easy to move in and out and interoperate with, linked to 
other closed tools (such as their issues tracker and their non-git pull 
requests system) which are harder to move out or interoperate. //


GitHub's API allows you to easily export issues if you want to move them 
somewhere else:

http://developer.github.com/v3/issues/

Pull-requests are used by repository hosting platforms to make it easier 
to suggest patches.  GitHub and BitBucket both use the pattern, and I 
don't understand what you mean by it being a closed tool.  If you're 
concerned about barriers to entry, suggesting a patch using only git 
or mercurial can be done, but I wouldn't say it's easy.


... and what Devon said.

-Shaun


On 2/21/13 9:34 AM, MJ Ray wrote:

Shaun Ellis sha...@princeton.edu

* Myth #1 : GitHub creates a barrier to entry.


That's a fact, not a myth.  Myself, I won't give GitHub my full legal
name and I suspect there are others who won't.  So, we're not welcome
there and if we lie to register, all our work would be subject to
deletion at an arbitrary future point.

There's a couple of other things in the terms which aren't simple, too.

[...]

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


Whether or not it's a deliberate monopolising attempt, I don't think
that's the full reason.  It's not only natural effect.  There's a
sneaky lock-in effect of having one open tool (git hosting) which is
fairly easy to move in and out and interoperate with, linked to other
closed tools (such as their issues tracker and their non-git pull
requests system) which are harder to move out or interoperate.

Use github if you like.  Just don't expect everyone to do so.

Hope that explains,

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-21 Thread Andrew Hankinson

Also, as a side note (and of interest to some) you *can* add pull requests to 
your repo:

https://gist.github.com/piscisaureus/3342247


On 2013-02-21, at 10:29 AM, Shaun Ellis sha...@princeton.edu wrote:

 If you read my email, I don't tell anyone what to use, but simply attempt to 
 clear up some fallacies.  Distributed version control is new to many, and I 
 want to make sure that folks are getting accurate information from this list.
 
 Unfortunately, this statement is not accurate either:
 
 // There's a sneaky lock-in effect of having one open tool (git hosting) 
 which is fairly easy to move in and out and interoperate with, linked to 
 other closed tools (such as their issues tracker and their non-git pull 
 requests system) which are harder to move out or interoperate. //
 
 GitHub's API allows you to easily export issues if you want to move them 
 somewhere else:
 http://developer.github.com/v3/issues/
 
 Pull-requests are used by repository hosting platforms to make it easier to 
 suggest patches.  GitHub and BitBucket both use the pattern, and I don't 
 understand what you mean by it being a closed tool.  If you're concerned 
 about barriers to entry, suggesting a patch using only git or mercurial can 
 be done, but I wouldn't say it's easy.
 
 ... and what Devon said.
 
 -Shaun
 
 
 On 2/21/13 9:34 AM, MJ Ray wrote:
 Shaun Ellis sha...@princeton.edu
 * Myth #1 : GitHub creates a barrier to entry.
 
 That's a fact, not a myth.  Myself, I won't give GitHub my full legal
 name and I suspect there are others who won't.  So, we're not welcome
 there and if we lie to register, all our work would be subject to
 deletion at an arbitrary future point.
 
 There's a couple of other things in the terms which aren't simple, too.
 
 [...]
 * 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.
 
 Whether or not it's a deliberate monopolising attempt, I don't think
 that's the full reason.  It's not only natural effect.  There's a
 sneaky lock-in effect of having one open tool (git hosting) which is
 fairly easy to move in and out and interoperate with, linked to other
 closed tools (such as their issues tracker and their non-git pull
 requests system) which are harder to move out or interoperate.
 
 Use github if you like.  Just don't expect everyone to do so.
 
 Hope that explains,

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-21 Thread Shaun Ellis


 Once again, these are not “fallacies”: they are disagreements.

When you say that GitHub is not team-centered, it's not a 
disagreement; it's simply false.  If you say I don't agree with the way 
GitHub implements the concept of teams, then that is a disagreement. 
You said the first, but perhaps you meant the second.


-Shaun

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-21 Thread Andrew Hankinson

An open tool is Internet email: I can send an email from my provider
(ucop.edu) to yours (princeton.edu). A closed tool is github, where I
need a github account to send you a pull request. An open tool would
be one where I can send a pull request bitbucket to github.
(Obviously, bitbucket is as closed as github in this regard.)

best, Erik
Sent from my free software system http://fsf.org/.

Uhh… That's a different definition of closed system than I'm used to seeing.
It's more akin to having a closed-source e-mail client vs. an open-source one.
The protocol (git) is open. I can push, pull, merge, fork, and do everything I
need to do with a repository without ever visiting GitHub -- even pushing and
pulling to/from pull requests. I can send you a patch that you can apply on
your Bitbucket repo without needing to touch GitHub. I can even do multiple
origins so that I can pull from GitHub but push to Bitbucket, and vice versa.
So while the tool may technically be closed-source, the protocol--the
equivalent to SMTP, IMAP, and POP in your example--is wide open.

Heck, even Richard Stallman gives GitHub a pass: I use the term SaaS for
services that do your computing for you, but not for services that do only
communication. Thus, gmail.com is not SaaS. Wordpress is not SaaS. Github is
not SaaS, or perhaps only in trivial ways.
(https://mayfirst.org/lowdown/august-2011/richard-m-stallman-lectures-free-software-west-bank)

GitHub makes a lot of things about using git collaboratively *easier*, but I
can do everything I need to on a collaborative project without ever visiting
the GitHub page itself, provided I don't want to look at the issue tracker or
wiki. The Pull Request button is just a shortcut to merging two remote
origins. If you wanted to make a system where you can send pull requests to
GitHub and Bitbucket, you can and nobody will stop you.

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-21 Thread Tom Johnson

Devon:

I don't think anyone is asking you to accommodate them in your choice of
tools or even approve of what they see as barriers. This conversation
started because of an understanding that the poetry folks *do want* to
accommodate others' needs and preferences. Taking that assumption in hand,
I don't think it's useful to dictate what counts as legitimate barriers for
other people. Their participation will be prevented to the same extent
whatever we think of their reasons.

That aside, I can think off-hand of a handful of reasons, near-and-dear to
FOSS, why a project contributor might not want identifying information
associated with their commits, and why the project coordinators might want
to make sure they don't have to. I might be contributing in my personal
time, but concerned that my employer would try to make copyright claims if
they could trace the code back to me. I might be contributing to security
projects like Tor or Whisper Systems, which has been known to cause trouble
at US borders for some people. Or, I might live under an oppressive
government which would object even more strongly to my choice of project.

These issues matter to a lot of us.

- Tom

On Thu, Feb 21, 2013 at 7:10 AM, Devon dec...@gmail.com wrote:

 If you're not willing to provide even your name to make use of a free
 service, then I dare say you are erecting your own barriers. Such is your
 choice, of course, but I don't think others need to be compelled
 to accommodate the barriers you create for yourself.

 And just because the terms of use are not unconditional, or perfectly to
 your liking, does not mean you're not welcome to use it. You are.

 /dev


 On Thu, Feb 21, 2013 at 9:34 AM, MJ Ray m...@phonecoop.coop wrote:

  Shaun Ellis sha...@princeton.edu
   * Myth #1 : GitHub creates a barrier to entry.
 
  That's a fact, not a myth.  Myself, I won't give GitHub my full legal
  name and I suspect there are others who won't.  So, we're not welcome
  there and if we lie to register, all our work would be subject to
  deletion at an arbitrary future point.
 
  There's a couple of other things in the terms which aren't simple, too.
 
  [...]
   * 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.
 
  Whether or not it's a deliberate monopolising attempt, I don't think
  that's the full reason.  It's not only natural effect.  There's a
  sneaky lock-in effect of having one open tool (git hosting) which is
  fairly easy to move in and out and interoperate with, linked to other
  closed tools (such as their issues tracker and their non-git pull
  requests system) which are harder to move out or interoperate.
 
  Use github if you like.  Just don't expect everyone to do so.
 
  Hope that explains,
  --
  MJ Ray (slef), member of www.software.coop, a for-more-than-profit
 co-op.
  http://koha-community.org supporter, web and library systems developer.
  In My Opinion Only: see http://mjr.towers.org.uk/email.html
  Available for hire (including development) at http://www.software.coop/
 



 --
 Sent from my GMail account.

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-21 Thread Devon

As far as the poetry goes, not my thing, so I don't have a comment on what
is actually used. The thread appeared to fork onto a discussion about
github use more generally. My apologies to all if it is still tightly
coupled to the poetry thing. The rest of my comments assume the more
general conversation.

MJ Ray had specific complaints - choosing not to have an account at all,
for ANY project. There are no doubt projects for which github is not
appropriate - all the examples you gave. There are countless more, however,
where it is a perfectly reasonable option. Choosing not to have an account
to participate in ANY project - no matter how trivial - is an individual's
choice. They certainly should not be coerced into getting one.

While no one has explicitly said accommodate me, it is implied in their
communications. The very nature of the original conversation was
people refuse to use github or feel the barriers imposed are too high and
therefore want others to make different choices - to accommodate their
choices. As far as the poetry thing goes, if the participants are
comfortable with that accommodation, then all is well and fine.

Like Jonathan, I think it was a mistake to post at all.

/dev



On Thu, Feb 21, 2013 at 1:44 PM, Tom Johnson johnson.tom+code4...@gmail.com
 wrote:

 Devon:

 I don't think anyone is asking you to accommodate them in your choice of
 tools or even approve of what they see as barriers. This conversation
 started because of an understanding that the poetry folks *do want* to
 accommodate others' needs and preferences. Taking that assumption in hand,
 I don't think it's useful to dictate what counts as legitimate barriers for
 other people. Their participation will be prevented to the same extent
 whatever we think of their reasons.

 That aside, I can think off-hand of a handful of reasons, near-and-dear to
 FOSS, why a project contributor might not want identifying information
 associated with their commits, and why the project coordinators might want
 to make sure they don't have to. I might be contributing in my personal
 time, but concerned that my employer would try to make copyright claims if
 they could trace the code back to me. I might be contributing to security
 projects like Tor or Whisper Systems, which has been known to cause trouble
 at US borders for some people. Or, I might live under an oppressive
 government which would object even more strongly to my choice of project.

 These issues matter to a lot of us.

 - Tom

 On Thu, Feb 21, 2013 at 7:10 AM, Devon dec...@gmail.com wrote:

  If you're not willing to provide even your name to make use of a free
  service, then I dare say you are erecting your own barriers. Such is your
  choice, of course, but I don't think others need to be compelled
  to accommodate the barriers you create for yourself.
 
  And just because the terms of use are not unconditional, or perfectly to
  your liking, does not mean you're not welcome to use it. You are.
 
  /dev
 
 
  On Thu, Feb 21, 2013 at 9:34 AM, MJ Ray m...@phonecoop.coop wrote:
 
   Shaun Ellis sha...@princeton.edu
* Myth #1 : GitHub creates a barrier to entry.
  
   That's a fact, not a myth.  Myself, I won't give GitHub my full legal
   name and I suspect there are others who won't.  So, we're not welcome
   there and if we lie to register, all our work would be subject to
   deletion at an arbitrary future point.
  
   There's a couple of other things in the terms which aren't simple, too.
  
   [...]
* 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.
  
   Whether or not it's a deliberate monopolising attempt, I don't think
   that's the full reason.  It's not only natural effect.  There's a
   sneaky lock-in effect of having one open tool (git hosting) which is
   fairly easy to move in and out and interoperate with, linked to other
   closed tools (such as their issues tracker and their non-git pull
   requests system) which are harder to move out or interoperate.
  
   Use github if you like.  Just don't expect everyone to do so.
  
   Hope that explains,
   --
   MJ Ray (slef), member of www.software.coop, a for-more-than-profit
  co-op.
   http://koha-community.org supporter, web and library systems
 developer.
   In My Opinion Only: see http://mjr.towers.org.uk/email.html
   Available for hire (including development) at
 http://www.software.coop/
  
 
 
 
  --
  Sent from my GMail account.
 




-- 
Sent from my GMail account.

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-21 Thread David Friggens

 If you're not willing to provide even your name to make use of a free
 service, then I dare say you are erecting your own barriers. Such is your
 choice, of course, but I don't think others need to be compelled
 to accommodate the barriers you create for yourself.

 And just because the terms of use are not unconditional, or perfectly to
 your liking, does not mean you're not welcome to use it. You are.

To all the people complaining about the Code4Lib 2014 conference
being unwelcoming because of our new No Clothes Policy, I say you are
wrong. We are entitled to enact our own conditions of entry, and if
you are unwilling to front up naked then you are just erecting your
own barriers. The conference is open and welcome to all - I hope to
see you there.

:-p

A different post mentioned namespace collisions - I actually don't
suffer from this, and because of my unique name I sometimes prefer not
to hand it over in certain circumstances (but GitHub wouldn't worry
me).

David

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-21 Thread Kyle Banerjee

On Thu, Feb 21, 2013 at 2:44 PM, David Friggens frigg...@waikato.ac.nzwrote:

 To all the people complaining about the Code4Lib 2014 conference
 being unwelcoming because of our new No Clothes Policy, I say you are
 wrong. We are entitled to enact our own conditions of entry, and if
 you are unwilling to front up naked then you are just erecting your
 own barriers. The conference is open and welcome to all - I hope to
 see you there.


Actually many organizations have exactly this policy. Though none that I've
heard of care about coding in libraries...
http://www.youtube.com/watch?v=pg5sRDJtqNc#t=4m42s

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-21 Thread Cary Gordon

Don't you mean  I hope to see all of you there.

On Thu, Feb 21, 2013 at 2:44 PM, David Friggens frigg...@waikato.ac.nz wrote:
 If you're not willing to provide even your name to make use of a free
 service, then I dare say you are erecting your own barriers. Such is your
 choice, of course, but I don't think others need to be compelled
 to accommodate the barriers you create for yourself.

 And just because the terms of use are not unconditional, or perfectly to
 your liking, does not mean you're not welcome to use it. You are.

 To all the people complaining about the Code4Lib 2014 conference
 being unwelcoming because of our new No Clothes Policy, I say you are
 wrong. We are entitled to enact our own conditions of entry, and if
 you are unwilling to front up naked then you are just erecting your
 own barriers. The conference is open and welcome to all - I hope to
 see you there.

 :-p

 A different post mentioned namespace collisions - I actually don't
 suffer from this, and because of my unique name I sometimes prefer not
 to hand it over in certain circumstances (but GitHub wouldn't worry
 me).

 David



-- 
Cary Gordon
The Cherry Hill Company
http://chillco.com

[CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Shaun Ellis


 (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

* 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



* 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




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

(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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Karen Coyle

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

* 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



* 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




* 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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Ethan Gruber

Wordpress?

On Wed, Feb 20, 2013 at 11:42 AM, Karen Coyle li...@kcoyle.net 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?

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/wikihttps://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/_**accesshttps://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-organizationshttps://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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Ross Singer

On Feb 20, 2013, at 11:42 AM, Karen Coyle li...@kcoyle.net 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?

Of course, these aren't mutually exclusive:

http://octopress.org/

-Ross.

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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Karen Coyle

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.

On 2/20/13 8:45 AM, Ethan Gruber wrote:

Wordpress?

On Wed, Feb 20, 2013 at 11:42 AM, Karen Coyle li...@kcoyle.net wrote:

On 2/20/13 8:20 AM, Shaun Ellis wrote:

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

* 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).

* 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)...

* Myth #4 : GitHub is monopolizing open source software development.

... to its unfortunate centralizing of so much free/open
source software on one platform.)

-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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Johnston, Leslie

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:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
 Karen Coyle
 Sent: Wednesday, February 20, 2013 12:07 PM
 To: CODE4LIB@LISTSERV.ND.EDU
 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 li...@kcoyle.net
 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/wikihttps://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/_**accessh
  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-
 organizationshttps://gith
  ub.com/blog/674-introducing-organizations

  * Myth #4 : GitHub is monopolizing open source software
 development

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Karen Coyle


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:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
Karen Coyle
Sent: Wednesday, February 20, 2013 12:07 PM
To: CODE4LIB@LISTSERV.ND.EDU
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 li...@kcoyle.net

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/wikihttps://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/_**accessh

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-

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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Jason Stirnaman

Another option might be to set it up like the Planet. Where individuals just 
post their poetry to their own blogs, Tumblrs, etc., tag them, and have 
$PLANET_NERD_POETS aggregate them.

Git and Github are great. But while I get the argument for utility, there does 
seem to be barrier-to-entry there for someone just wanting to submit a poem.

Jason

Jason Stirnaman
Digital Projects Librarian
A.R. Dykes Library
University of Kansas Medical Center
913-588-7319


From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Karen Coyle 
[li...@kcoyle.net]
Sent: Wednesday, February 20, 2013 10:42 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

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

 * 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

 

 * 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

 

 * 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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Erik Hetzner

At Wed, 20 Feb 2013 11:20:33 -0500,
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.

It does matter what tools you use, which is why people are so
passionate about them. But I agree completely that you need to balance
the preferences of the community.

 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:

It’s not confusion; and these aren’t “myths”: they are disagreements.

best, Erik
Sent from my free software system http://fsf.org/.


pgpB5ekrOeqHs.pgp
Description: PGP signature

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Tom Johnson

 But while I get the argument for utility, there does seem to be
barrier-to-entry there for someone just wanting to submit a poem.

The original suggestion wasn't about utility, but about modes of writing.
Git repositories would make for poems which are easily shared, copied,
forked, and merged back together. I'm interested in the relationship this
has to the idea of an oral tradition. Especially given that a git
poetry tradition would record its own history in the medium.

I agree that wordpress is much more accessible. It seems obvious to me that
we could post poems where we see fit and aggregate them. Written and oral
is even more accessible than that. It seems obvious to me that we could
write down and/or recite poems, pass them around, and commit them to
memory. I think we should do all these things--and maybe play around with
git, too.

For me, the important take away from this discussion is that git art
shouldn't be the dominant form of expression or the raison d'etre for the
'nerd poetry' idea.

As an aside: I share the concerns about GitHub. I resisted joining for
years because of exactly this issue. If Facebook is a man-in-the-middle
exploit on social interaction, then surely GitHub is the same on Free
Software development. I thought the FOSS community would be better served
if we all put up our git repositories in our own ways, and tried to build
tools for collaboration. As it turns out, GitHub has done wonders for code
sharing and collaborative development and the company has been good to us,
which is why I'm there now. I still worry about ways the our platform
dependence could go badly. Luckily, the risk is mitigated by gits
distributed and portable nature.

- Tom


On Wed, Feb 20, 2013 at 10:20 AM, Jason Stirnaman jstirna...@kumc.eduwrote:

 Another option might be to set it up like the Planet. Where individuals
 just post their poetry to their own blogs, Tumblrs, etc., tag them, and
 have $PLANET_NERD_POETS aggregate them.

 Git and Github are great. But while I get the argument for utility, there
 does seem to be barrier-to-entry there for someone just wanting to submit a
 poem.

 Jason

 Jason Stirnaman
 Digital Projects Librarian
 A.R. Dykes Library
 University of Kansas Medical Center
 913-588-7319

 
 From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Karen
 Coyle [li...@kcoyle.net]
 Sent: Wednesday, February 20, 2013 10:42 AM
 To: CODE4LIB@LISTSERV.ND.EDU
 Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

 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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Benjamin Armintor

You are definitely insulated from loss of material by the distributed
character of git, but it would be difficult to replace the social network
around the projects. You really see this when you work with a non-Github
git repository: Getting a copy of it is trivial, but you have no mechanism
for alerting the original repository (much less its network) of potentially
valuable changes. Of course, there's the old-fashioned splash-pages and
contact emails, but the relative triviality of advertising changes to a
Github repository (and accepting them, for that matter) is pretty
groundbreaking.

- Ben


On Wed, Feb 20, 2013 at 2:04 PM, Tom Johnson johnson.tom+code4...@gmail.com
 wrote:

  But while I get the argument for utility, there does seem to be
 barrier-to-entry there for someone just wanting to submit a poem.

 The original suggestion wasn't about utility, but about modes of writing.
 Git repositories would make for poems which are easily shared, copied,
 forked, and merged back together. I'm interested in the relationship this
 has to the idea of an oral tradition. Especially given that a git
 poetry tradition would record its own history in the medium.

 I agree that wordpress is much more accessible. It seems obvious to me that
 we could post poems where we see fit and aggregate them. Written and oral
 is even more accessible than that. It seems obvious to me that we could
 write down and/or recite poems, pass them around, and commit them to
 memory. I think we should do all these things--and maybe play around with
 git, too.

 For me, the important take away from this discussion is that git art
 shouldn't be the dominant form of expression or the raison d'etre for the
 'nerd poetry' idea.

 As an aside: I share the concerns about GitHub. I resisted joining for
 years because of exactly this issue. If Facebook is a man-in-the-middle
 exploit on social interaction, then surely GitHub is the same on Free
 Software development. I thought the FOSS community would be better served
 if we all put up our git repositories in our own ways, and tried to build
 tools for collaboration. As it turns out, GitHub has done wonders for code
 sharing and collaborative development and the company has been good to us,
 which is why I'm there now. I still worry about ways the our platform
 dependence could go badly. Luckily, the risk is mitigated by gits
 distributed and portable nature.

 - Tom


 On Wed, Feb 20, 2013 at 10:20 AM, Jason Stirnaman jstirna...@kumc.edu
 wrote:

  Another option might be to set it up like the Planet. Where individuals
  just post their poetry to their own blogs, Tumblrs, etc., tag them, and
  have $PLANET_NERD_POETS aggregate them.
 
  Git and Github are great. But while I get the argument for utility, there
  does seem to be barrier-to-entry there for someone just wanting to
 submit a
  poem.
 
  Jason
 
  Jason Stirnaman
  Digital Projects Librarian
  A.R. Dykes Library
  University of Kansas Medical Center
  913-588-7319
 
  
  From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Karen
  Coyle [li...@kcoyle.net]
  Sent: Wednesday, February 20, 2013 10:42 AM
  To: CODE4LIB@LISTSERV.ND.EDU
  Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)
 
  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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Tom Johnson

 but it would be difficult to replace the social network around the
projects.

Especially difficult now that GitHub is where the community is. It's
technically possible to build a social web that works on a decentralized
basis, but it may no longer be culturally possible. Platforms are hard to
get down from.

On Wed, Feb 20, 2013 at 11:12 AM, Benjamin Armintor armin...@gmail.comwrote:

 You are definitely insulated from loss of material by the distributed
 character of git, but it would be difficult to replace the social network
 around the projects. You really see this when you work with a non-Github
 git repository: Getting a copy of it is trivial, but you have no mechanism
 for alerting the original repository (much less its network) of potentially
 valuable changes. Of course, there's the old-fashioned splash-pages and
 contact emails, but the relative triviality of advertising changes to a
 Github repository (and accepting them, for that matter) is pretty
 groundbreaking.

 - Ben


 On Wed, Feb 20, 2013 at 2:04 PM, Tom Johnson 
 johnson.tom+code4...@gmail.com
  wrote:

   But while I get the argument for utility, there does seem to be
  barrier-to-entry there for someone just wanting to submit a poem.
 
  The original suggestion wasn't about utility, but about modes of writing.
  Git repositories would make for poems which are easily shared, copied,
  forked, and merged back together. I'm interested in the relationship
 this
  has to the idea of an oral tradition. Especially given that a git
  poetry tradition would record its own history in the medium.
 
  I agree that wordpress is much more accessible. It seems obvious to me
 that
  we could post poems where we see fit and aggregate them. Written and oral
  is even more accessible than that. It seems obvious to me that we could
  write down and/or recite poems, pass them around, and commit them to
  memory. I think we should do all these things--and maybe play around with
  git, too.
 
  For me, the important take away from this discussion is that git art
  shouldn't be the dominant form of expression or the raison d'etre for the
  'nerd poetry' idea.
 
  As an aside: I share the concerns about GitHub. I resisted joining for
  years because of exactly this issue. If Facebook is a man-in-the-middle
  exploit on social interaction, then surely GitHub is the same on Free
  Software development. I thought the FOSS community would be better served
  if we all put up our git repositories in our own ways, and tried to build
  tools for collaboration. As it turns out, GitHub has done wonders for
 code
  sharing and collaborative development and the company has been good to
 us,
  which is why I'm there now. I still worry about ways the our platform
  dependence could go badly. Luckily, the risk is mitigated by gits
  distributed and portable nature.
 
  - Tom
 
 
  On Wed, Feb 20, 2013 at 10:20 AM, Jason Stirnaman jstirna...@kumc.edu
  wrote:
 
   Another option might be to set it up like the Planet. Where individuals
   just post their poetry to their own blogs, Tumblrs, etc., tag them, and
   have $PLANET_NERD_POETS aggregate them.
  
   Git and Github are great. But while I get the argument for utility,
 there
   does seem to be barrier-to-entry there for someone just wanting to
  submit a
   poem.
  
   Jason
  
   Jason Stirnaman
   Digital Projects Librarian
   A.R. Dykes Library
   University of Kansas Medical Center
   913-588-7319
  
   
   From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Karen
   Coyle [li...@kcoyle.net]
   Sent: Wednesday, February 20, 2013 10:42 AM
   To: CODE4LIB@LISTSERV.ND.EDU
   Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)
  
   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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Mark A. Matienzo

Regarding forking and WordPress:
http://wordpress.org/extend/plugins/post-forking/

WordPress Post Forking allows users to fork or create an alternate
version of content to foster a more collaborative approach to
WordPress content curation. This can be used, for example, to allow
external users (such as visitors to your site) or internal users (such
as other authors) with the ability to submit proposed revisions. It
can even be used on smaller or single-author sites to enable post
authors to edit published posts without their changes appearing
immediately. If you're familiar with Git, or other decentralized
version control systems, you're already familiar with WordPress post
forking.

Mark


On Wed, Feb 20, 2013 at 2:51 PM, Jason Stirnaman jstirna...@kumc.edu wrote:
 Git repositories would make for poems which are easily shared, copied,
 forked, and merged back together. I'm interested in the relationship this
 has to the idea of an oral tradition.

 Point taken. That's a really interesting idea. Sorry that I jumped in at the 
 middle.

 I think we should do all these things--and maybe play around with
 git, too.

 Agreed. So, distilling some of the key ideas from the thread:
 1. Keep it simple for anyone to share a poem.
 2. Help those poems find an audience (aka, more nerds for starters).
 3. Allow the audience to comment on the poems.
 4. Help other people share, adapt, fork, the poems.
 5. Help the poems persist and record their history as they go.

 Jason

 
 From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Tom Johnson 
 [johnson.tom+code4...@gmail.com]
 Sent: Wednesday, February 20, 2013 1:04 PM
 To: CODE4LIB@LISTSERV.ND.EDU
 Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

 But while I get the argument for utility, there does seem to be
 barrier-to-entry there for someone just wanting to submit a poem.

 The original suggestion wasn't about utility, but about modes of writing.
 Git repositories would make for poems which are easily shared, copied,
 forked, and merged back together. I'm interested in the relationship this
 has to the idea of an oral tradition. Especially given that a git
 poetry tradition would record its own history in the medium.

 I agree that wordpress is much more accessible. It seems obvious to me that
 we could post poems where we see fit and aggregate them. Written and oral
 is even more accessible than that. It seems obvious to me that we could
 write down and/or recite poems, pass them around, and commit them to
 memory. I think we should do all these things--and maybe play around with
 git, too.

 For me, the important take away from this discussion is that git art
 shouldn't be the dominant form of expression or the raison d'etre for the
 'nerd poetry' idea.

 As an aside: I share the concerns about GitHub. I resisted joining for
 years because of exactly this issue. If Facebook is a man-in-the-middle
 exploit on social interaction, then surely GitHub is the same on Free
 Software development. I thought the FOSS community would be better served
 if we all put up our git repositories in our own ways, and tried to build
 tools for collaboration. As it turns out, GitHub has done wonders for code
 sharing and collaborative development and the company has been good to us,
 which is why I'm there now. I still worry about ways the our platform
 dependence could go badly. Luckily, the risk is mitigated by gits
 distributed and portable nature.

 - Tom


 On Wed, Feb 20, 2013 at 10:20 AM, Jason Stirnaman jstirna...@kumc.eduwrote:

 Another option might be to set it up like the Planet. Where individuals
 just post their poetry to their own blogs, Tumblrs, etc., tag them, and
 have $PLANET_NERD_POETS aggregate them.

 Git and Github are great. But while I get the argument for utility, there
 does seem to be barrier-to-entry there for someone just wanting to submit a
 poem.

 Jason

 Jason Stirnaman
 Digital Projects Librarian
 A.R. Dykes Library
 University of Kansas Medical Center
 913-588-7319

 
 From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Karen
 Coyle [li...@kcoyle.net]
 Sent: Wednesday, February 20, 2013 10:42 AM
 To: CODE4LIB@LISTSERV.ND.EDU
 Subject: Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

 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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Jonathan Rochkind

Probably a mistake for me to post at all, but I'm full of mistakes. You 
know what, if someone wants to set up a spot for nerd poetry, I think 
they should do so. If someone else wants to set up a different spot 
using different tech, I think they should do so too.


I think it's mistaken to think anyone needs to reach consensus on what 
the 'right' technology or spot for this is; and I also think it's 
mistaken to think that any one platform or technology is going to be 
thought to be the best by everyone involved, differnet people will 
always have different opinions.   I also think it's a mistake to get 
offended because what someone else feels like experimenting with setting 
up is not something you think is the best way to do it.


Most piece of code4lib 'social' tech, going back to this mailing list 
itself, was created by someone who felt like creating it because they 
thought it would be fun and rewarding, and they did so.


Now, if you want to discuss the technical pro's and con's of different 
technical options, or even some technical how-to's, I think that would 
be a great use of the code4lib listserv.

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Johnston, Leslie

Ah, my bad.

 -Original Message-
 From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
 Karen Coyle
 Sent: Wednesday, February 20, 2013 1:15 PM
 To: CODE4LIB@LISTSERV.ND.EDU
 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:CODE4LIB@LISTSERV.ND.EDU] On Behalf
  Of Karen Coyle
  Sent: Wednesday, February 20, 2013 12:07 PM
  To: CODE4LIB@LISTSERV.ND.EDU
  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 li...@kcoyle.net
  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/wikihttps://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/_**accessh
  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

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

2013-02-20 Thread Erik Hetzner

At Wed, 20 Feb 2013 11:50:45 -0800,
Tom Johnson wrote:
 
  but it would be difficult to replace the social network around the
 projects.
 
 Especially difficult now that GitHub is where the community is. It's
 technically possible to build a social web that works on a decentralized
 basis, but it may no longer be culturally possible. Platforms are hard to
 get down from.

Maybe. Most people today use internet email, not Compuserve email;
they use the web, not AOL keywords; and they use jabber/xmpp, not ICQ.
I don’t think it’s unreasonable to think that people will eventually
leave twitter for a status.net implementation, or github for something
else.

best, Erik
Sent from my free software system http://fsf.org/.


pgpxpukkELTRd.pgp
Description: PGP signature

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

[CODE4LIB] IRC and mail was Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

[CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

Re: [CODE4LIB] GitHub Myths (was thanks and poetry)

29 matches

Site Navigation

Mail list logo

Footer information