Anonymous

User:Martind: Difference between revisions

From London Hackspace Wiki
no edit summary
No edit summary
Line 63: Line 63:
* [http://reddragdiva.co.uk/lj/group_enemy.html A Group Is Its Own Worst Enemy], on the need for barriers to entry and controlled community growth.
* [http://reddragdiva.co.uk/lj/group_enemy.html A Group Is Its Own Worst Enemy], on the need for barriers to entry and controlled community growth.
* Joseph Reagle, [http://firstmonday.org/ojs/index.php/fm/article/view/4291/3381 “Free as in sexist?” Free culture and the gender gap], which argues that: "(a) some geek identities can be narrow and unappealing; (b) open communities are especially susceptible to difficult people; and, (c) the ideas of freedom and openness can be used to dismiss concerns and rationalize the gender gap as a matter of preference and choice."
* Joseph Reagle, [http://firstmonday.org/ojs/index.php/fm/article/view/4291/3381 “Free as in sexist?” Free culture and the gender gap], which argues that: "(a) some geek identities can be narrow and unappealing; (b) open communities are especially susceptible to difficult people; and, (c) the ideas of freedom and openness can be used to dismiss concerns and rationalize the gender gap as a matter of preference and choice."
* "[https://www.msu.edu/~zpneal/publications/neal-diversitysoc.pdf The (In)compatibility of Diversity and Sense of Community]" (PDF), simulations suggest group diversity is in conflict with group cohesion -- another argument for forming interest groups within large diverse communities to maintain overall cohesion ([http://www.theatlanticcities.com/neighborhoods/2013/11/paradox-diverse-communities/7614/ commentary])
* etc.
* etc.


Line 70: Line 69:
(This section is still new, will be refined over time.)
(This section is still new, will be refined over time.)


A great discussion of Wikipedia's struggle to deal with growth and simultaneously retain new users: "[http://www-users.cs.umn.edu/~halfak/publications/The_Rise_and_Decline/ The Rise and Decline of an Open Collaboration Community: How Wikipedia's reaction to sudden popularity is causing its decline]". The similarities to LHS growth patterns are striking.
=== Limits to Heterogeneity? ===
 
Atm there's an implicit assumption that the LHS is a space to practice a particular shared culture (hacker/maker/open source/sharing/...) As we grow more newcomers have not been exposed to this culture. (These are: short-term users, newcomers, purely self-interested users, ...)
* I think there's great value in building safe teaching spaces to learn the culture; pledge drives and social nights work well I think, and I'm still hoping the Hack the Space Day will become more popular
* but of course: can't expect that everyone *wants* to learn the culture.
 
There's an open question in this: how do we want to handle with people who don't want to learn the culture? (Because they don't know better, haven't learned yet; or because they disagree/refuse)
* do we still want to support them?
* is our (limited) energy best spent on converting them?
* are there systematic means of still letting them interact in productive ways, somehow channeling their self-interest into things that benefit the org?
* when do they become a liability?


Summary:
=== Mistakes are Stepping Stones for Newcomers ===
* automated reversion tools help reduce spam, but users employing them on newcomers' edits don't often explain why edits are reverted, which alienates new people
** LHS: the "rule hammer" may get applied to newcomers' transgressions too quickly without always explaining well what just happened
* there's a great barrier to entry when formulating policy changes, hard for newcomers to engage, and newcomer considerations are consequently not included well


I think it's important to make mistakes, they're often key steps in the long process of becoming familiar with our culture, and there's no need to shout at people for having screwed up once. Instead a perceived "transgression" should be an opportunity for a conversation; a chance to convert ("de-program") a newcomer.
I think it's important to make mistakes, they're often key steps in the long process of becoming familiar with our culture, and there's no need to shout at people for having screwed up once. Put your rule hammer away! Instead a perceived "transgression" should be an opportunity for a conversation; a chance to provide context, to explain our expectations, to convert ("de-program") a newcomer.


So I'm thinking…
So I'm thinking…
Line 86: Line 92:
** of course that's hard to reconcile with our very informal approach to policy-making
** of course that's hard to reconcile with our very informal approach to policy-making


Atm there's an implicit assumption that the LHS is a space to practice a particular shared culture (hacker/maker/open source/sharing/...) As we grow more newcomers have not been exposed to this culture. (These are: short-term users, newcomers, purely self-interested users, ...)
=== Subgroups as Growth Mechanism ===
* I think there's great value in building safe teaching spaces to learn the culture; pledge drives and social nights work well I think, and I'm still hoping the Hack the Space Day will become more popular
* but of course: can't expect that everyone *wants* to learn the culture.
 
There's an open question in this: how do we want to handle with people who don't want to learn the culture? (Because they don't know better, haven't learned yet; or because they disagree/refuse)
* do we still want to support them?
* is our (limited) energy best spent on converting them?
* are there systematic means of still letting them interact in productive ways, somehow channeling their self-interest into things that benefit the org?
* when do they become a liability?


Finally there's a discussion to have around group cohesion and growth. I'm quite interested in moving towards a "federated/syndicated" model of operations: to foster the formation of subgroups (meetups, special-interest groups, regular workshops, …) within the LHS that manage their own space/resources. This doesn't have to be very formal.  
Finally there's a discussion to have around group cohesion and growth. I'm quite interested in moving towards a "federated/syndicated" model of operations: to foster the formation of subgroups (meetups, special-interest groups, regular workshops, …) within the LHS that manage their own space/resources. This doesn't have to be very formal.  
Line 101: Line 99:
** I'm interested in fostering a stronger culture of group-maintained infrastructure, as opposed to our previous "we all are responsible" (i.e., nobody feels responsible) model.  
** I'm interested in fostering a stronger culture of group-maintained infrastructure, as opposed to our previous "we all are responsible" (i.e., nobody feels responsible) model.  
** Subgroups can be interested in keeping particular infrastructure in a working state, and can develop the skills/resources to maintain it.
** Subgroups can be interested in keeping particular infrastructure in a working state, and can develop the skills/resources to maintain it.
=== Recommended Reading ===
* "[http://www-users.cs.umn.edu/~halfak/publications/The_Rise_and_Decline/ The Rise and Decline of an Open Collaboration Community: How Wikipedia's reaction to sudden popularity is causing its decline]". A great discussion of Wikipedia's struggle to deal with growth and simultaneously retain new users. The similarities to LHS growth patterns are striking:
** Automated reversion tools help reduce spam, but users employing them on newcomers' edits don't often explain why edits are reverted, which alienates new people. (LHS: the "rule hammer" and "ban hammer")
** there's a great barrier to entry when formulating policy changes, hard for newcomers to engage, and newcomer considerations are consequently not included well
* "[https://www.msu.edu/~zpneal/publications/neal-diversitysoc.pdf The (In)compatibility of Diversity and Sense of Community]" (PDF), simulations suggest group diversity is in conflict with group cohesion -- another argument for forming interest groups within large diverse communities to maintain overall cohesion ([http://www.theatlanticcities.com/neighborhoods/2013/11/paradox-diverse-communities/7614/ commentary])


== Spc Mgmt ==
== Spc Mgmt ==