View source for Guide/HumanDimension

== About this page ==
This is currently a scratch page, to develop a "chair training module" on the Human Dimension - dealing with people in Working Groups.

Please feel free to edit this page directly.

The initial live sessions on 17 June 2014 gathered issues, scenarios and thoughts on them. There were 2 sessions, and the [http://www.w3.org/2014/06/17-chairing-minutes.html minutes of the meetings] are available.

== The Chair ==
Obviously, it is important that the chair is helpful to the group, rather than an obstacle to making progress. There are several ways that a chair can be a problem - and sometimes the main requirement is to find a balance between two extremes, either of which are unproductive.
=== Don't be the problem ===
One of the most important tasks of a chair is to set the tone for a group. If you are overly aggressive, rude, dismissive, etc, people will follow your lead. On the other hand, a good example is harder to follow, so you have to do more of it.
=== Giving your opinion ===
Chairs at W3C are volunteers, and except in a few cases are likely to have an opinion on technical questions the group faces. How do we distinguish between being a chair and being a participant?
=== Queues ===
It is, in principle, up to the chair to manage the queue. But also to take a place in the queue. This is often hard, but generally useful
=== Know your tools ===
It is helpful if chairs understand the tools that are available, and use them effectively. [http://www.w3.org/2014/Talks/0423-tools-rrs/#(1) Chair training slides on W3C tools, 2014] is a useful resource.

== Group Dynamics ==
=== Fatigue ===
People get tired. They don't work well when they are. 
=== Tone - aggression and inclusion ===
These things are important to balance. It is possible to lose people who think the group isn't prepared to face up to real issues. It is easy to lose people who find the group a threatening, confronting, or unpleasant place to try and work.
=== What if we consider… (Again!!) ===
When new people join a group, do they propose solutions that have already been examined and rejected?
=== Organising Meetings ===
How to get people to come to meetings? Does remote participation help or hinder?
Do we need to have catered lunch and dinner?
=== Scribing ===
Scribing is a task that is important. Very often, a few people do a lot of the work, a lot of people don't want to do it, and most people are not very good at it.
=== Everyone, Anyone, Someone, Nobody ===
Everyone knew that Anyone could do what was needed, and all agreed Someone should. But Nobody ended up doing it. How to make sure this isn't the story of your group?
*Distinguishing volunteers who are too busy from people who are obstructing work with delay is difficult.
*Moving people around tasks can help get them focused on something appropriate
*Regular review of Action items can give the group a sense for when it is relying too heavily on someone who cannot deliver "in time"
=== The spec is not good yet, but everyone wants it ===
Product pressure is so high, that even bad specs are promoted to move forward. How to balance quality and need, and avoid running into a wall or having people walk away from the group.
=== A small group gets no feedback from the real world ===
(that may not be a human problem)
Groups of experts are sometimes the only one being able to judge the relevance of their own work. How to get more feedback from the developer world ?
=== It's easier to work outside the group ===
We'll just bring stuff for the group to rubber-stamp, OK?

This risks failing the basic test of whether the process is fair - for some members that is an important protection prosecution for anti-competitive behaviour, or cartel activity. It also makes it harder to track IPR contributions, which weakens the strength of the RF license given by the members.

== Different individuals ==
There are people who have particular requirements based on medical needs, religious convictions, etc. Is balancing these needs with those of the rest of the group a problem?
=== Religion ===
*W3C doesn't have any particular religion. But individuals who do are often unavailable at specific times.
*Is a religious statement in an email signature acceptable? (This is a real question)
=== Accessibility Requirements ===
*Blind participants will need some specific information
*Physical disabilities can restrict places WG members can go

== Difficult individuals ==
There is a difference between having a specific need, and being difficult to get along with. But it isn't always cut and dried.
=== Chairing from the floor ===
Are there participants who insist on "trying to run the meeting", ignoring the chair?

=== Bypassing the chair ===
What if a participant neither tries to run the meeting nor consults the chair but simply operates as though they are the only member?
=== There is only one valid voice : mine ===
An editor does not listen to others contributions, following his or her own strategy.
=== Blockers ===
Working Groups are composed of people whose employers are often business rivals looking for competitive advantage. What can a chair do if someone is essentially playing a negative role, trying to slow the group down or make it spend a lot of time on something as a way of tying up their rivals in pointless work? How to identify this kind of situation?

Putting work into task forces may focus attention, making blockers stand out because there is no audience left who are unfamiliar with the work but go along with what others suggest.