Difference between pages "ClsXlca2015 recognition" and "Group Roles"

From LCA2016 Delegate wiki
(Difference between pages)
Jump to: navigation, search
 
(Created page with " == Group discussion roles == Call for a volunteer to take on each of these roles. === Facilitator === The facilitator sets the topic and tone of the discussion and guides...")
 
Line 1: Line 1:
Notes from clsXlca 2015 Recognition discussion
 
  
Recognition
+
== Group discussion roles ==
  
What do we mean by "Recognition"?
+
Call for a volunteer to take on each of these roles.
  
How would you like to be recognised?
 
  
Recognise contributions to a greater effort.
+
=== Facilitator ===
  
What does it look like?
+
The facilitator sets the topic and tone of the discussion and guides the conversation. Facilitators should try to make sure everyone who wants to contribute gets a chance to do so, and no one or two people dominates the discussion too much.
  
(Individual Experiences)
 
** Verbal
 
** Specific, timely and explicit
 
** Linked to org/communities goals
 
  
From whom?
+
=== Notetaker ===
** Leaders giving thanks has certain gravitas
+
** Peers giving thanks means something different
+
** 'Members' giving thanks to 'Leaders' for doing leadership things is rare and just as highly valued.
+
  
Some people prefer their recognition to be private. Some prefer it to be public.
+
The notetaker creates a record of the discussion. Notes will be shared with others or used as the basis for ongoing work. The notetaker should check the notes are accurate, and that everyone is happy to share them.
  
1:1 directed thanks is powerful; in person is often preferred within our discussion group; email, replies to public postings on mailing-lists/forums are all nice too.
 
  
How do we foster a culture of recognition?
+
=== Notetaker ===
  
Acknowledging code contributions and seeing them being used. Having patches merged in by that person who the community knows only merges the very best patches is a form of recognition, but it's not an accessible form to newbies who don't have that map yet.
+
The notetaker creates a record of the discussion. Notes will be shared with others or used as the basis for ongoing work. The notetaker should check the notes are accurate, and that everyone is happy to share them.
  
Other people engaging with your code, either by linking to it, building on top of it, or extending it are forms of passive recognition that you're building something useful.
 
  
When a peer comes to you and says "that's a beautiful piece of work" (verbal, face-to-face worked. email didn't work for this person).
+
=== Timekeeper ===
  
Recognising consistently good work is equally important as recognising someone raising their work to that level.
+
The timekeeper watches the clock for everyone in the group. Keep time for the session as a whole, but also help everyone have their chance to speak. eg. Let people know their time is up, by saying "Thank you".
 
+
One piece of recognition is a project leader tweeting that someone made a strong contribution to a release and that was excellent.
+
 
+
If the recognition is written down it allows the recognised contributor to return to it at times when they are feeling like an imposter and get a boost.
+
 
+
Sometimes when you're the public face of a team or group, you will get the recognition for the work they do and you want to pass that on but don't know how.
+
 
+
One person liked it privately, really specific and didn't tend to return to the recognition.
+
 
+
Some times gifts work, not starbucks gift cards, but cultural artifacts (things that relate to the mascot), techie gifts and whiskey are all examples of gifts that work. Some people give team based swag (tshirts) which provides identity and recognition.
+
 
+
Relating it to personal or organisational roles makes it more powerful.
+
 
+
One way we recognise someone is by introducing them to other people and saying "This is $foo, they fixed that awful bug we had sitting in the tracker for weeks and they're awesome."
+
 
+
We recogonise people by attending their talks at cons and paying attention.
+
 
+
Some times recognition comes in the form of grant money for an org's goals or funding a specific development effort.
+
 
+
If you don't know how to recognise someone's work you can ask them what recognition they want. You may have to manage an unrealistic or impractical request/expectation here. [ASCII DRAGONS? ;)]
+
 
+
When you do your release blog/notes/files include everyone who contributed to the community in the thanks.
+
 
+
Code is tracked by SCMs. Translations are sometimes tracked by specific translation tools, sometimes by SCMs. Art assets in SCMs. Other contributions to the community tended to be tracked in peoples heads or in email archives (having project-by-project email aliases is useful here). There may or may not be a good technical solution to tracking these.
+
 
+
There are tools for tracking and reporting on metrics on who's replying to emails, irc requests and forums (http://bitergia.com/).
+
 
+
Some of the tools we use to track attribution don't work right for all use cases (author, reviewer/comitter, QA).
+
 
+
Metrics can't trump culture. There was talk about how gamifingy sometimes works but sometimes causes more problems. Fostering a 'culture of recognition'.
+
 
+
Discuss the ways in which you do your recognition.
+
 
+
Sometimes recognition is tied to the release cycle, some times it's periodic.  
+
 
+
Recognition can lead to a feeling of belonging which can lead to engagement.
+
 
+
When people submit pull requests a bot replies on github with a 'we'll get back to you within X amount of time'. It was suggested that people who contribute to maintaining that SLA could be thanked.
+
 
+
Examples:
+
 
+
An org bought a bunch of postcards and at the end of a con told their attendees to write thankyous to people who couldn't be at the con and the org then posted them out.
+
 
+
One team member bought a bunch of hats which their projects mascot wears and sent them out to the core dev team.
+
 
+
We give commit access as recognition of work and sometimes maintainership as recognition of awesome.
+
 
+
Release notes, Authors files, commit logs.
+
 
+
Merging code is recognition of the contribution.
+
 
+
In Openstack, regular code contributors get ATC status which gives them voting rights on tech ballots for a year (there are other ways to get ATC status too).
+
 
+
Some websites put badges next to the user profile or the user name when they post.
+
 
+
"Shout Out Wall" (post it notes on a wall at cons to give thanks).
+
 
+
[[category: CLSXLCA]]
+

Revision as of 20:40, 23 January 2016

Group discussion roles

Call for a volunteer to take on each of these roles.


Facilitator

The facilitator sets the topic and tone of the discussion and guides the conversation. Facilitators should try to make sure everyone who wants to contribute gets a chance to do so, and no one or two people dominates the discussion too much.


Notetaker

The notetaker creates a record of the discussion. Notes will be shared with others or used as the basis for ongoing work. The notetaker should check the notes are accurate, and that everyone is happy to share them.


Notetaker

The notetaker creates a record of the discussion. Notes will be shared with others or used as the basis for ongoing work. The notetaker should check the notes are accurate, and that everyone is happy to share them.


Timekeeper

The timekeeper watches the clock for everyone in the group. Keep time for the session as a whole, but also help everyone have their chance to speak. eg. Let people know their time is up, by saying "Thank you".