Thinking about communication process
Apology for the delayed response -- lots on my plate at the moment and preparing for an international trip.
I agree -- the charter should include a section on how the group will communicate. Rather than specify specific technologies, we can think about the criteria / checklist of requirements for the communication strategy, for example, we could specify that work group communications should:
- Be transparent -- i.e any member of the community must be able to read and access the communications
- Be open -- i.e. that any member must be able to contribute to the discussions. This also includes a requirement to use open file formats, in other words contributors should not be required to purchase non-free software in order to participate in the discussions.
- Be licensed as free content (i.e. CC-BY, or CC-BY-SA or published under a public domain declaration)
- all discussions are conducted in the same place, with clearly identified links to where the discussions are taking place.
I think the charter should also specify a suggested time line with reasonable and achievable target dates. In addition, I think their should be regular communications on the main list about progress -- possibly a short report -- maximum of one page on progress against the suggested timeline.
I also think the charter should include a very brief reflection on the skills / experience of the workgroup --- this is not to restrict participation of members who may not necessarily have relevant or appropriate experience --- but rather a mechanism to identify if a workgroup has any skills gaps so that we can recruit additional skills from our community.
I like the idea of having a bash at developing a charter for this workgroup --- this will help us identify the requirements for a charter. Incremental learn-by-doing --- the wiki way :-).
Wayne, No need to apologize.
Communication -- you're right, listing the requirements for communication is better than listing methods. Participants will have their favored communication methods and can evaluate them against the specs.
Outcomes -- agree that outcomes should have specified target dates.
Maybe your suggestion on regular communication to the main WE list is part of supporting Workgroups. One way to keep something going is to keep it visible.
Skills/experience -- implemented a 2-way table in our charter as a trial balloon.
The charter is started. Let's see where it goes and what we can learn (:-D.
Yip --- progress is looking good.
The skills table is a great start. Thinking a little wider here that is the skills specification for future workgroups perhaps it would be better to invite the volunteer members of the workgroup to write a succinct statement of their relevant skills pertaining to the workgroup -- no more than a sentence with a link to their userpage. So for example in my case I could write something like:
- Founder of WikiEducator, elected member of Council with governance, senior level management and leadership experience -- link to User page goes here.
In this way volunteers can identify their relevant experience and interests in a more flexible way and readers and reviewers can quickly scan the experience of the group.
Coming back to a point which I think you made earlier -- we should think about clarifying roles of workgroup participants:
eg Convenor / co-convenor -- responsible for:
- Convening and facilitating workgroup discussions
- Ensuring the development of a charter in accordance with the guidelines and recommended criteria
- Taking responsibility for regular updates on the main list
- Taking proactive initiative to ensure that volunteers are kept up to date (eg personal email, reminders of deadlines etc.)
- Prepare final submission of the work group proposal for Council (in the case of community-wide workgroups).
- Regularly visit the work group page
- Contribute to discussions and draft reviews of the workgroup outputs
- Aim to achieve consensus on relevant items
Other roles? Thoughts?
Your suggestion to have each participant include a short bit summarizing their relevant skills and experience was my first thought also. I even created a test layout, but wondered if a more concise display (2-way table) would be better.
I've got both versions included now (I reset your suggestion with the linked name first instead of last). Not sure both are needed -- it seems like overkill, but I'll leave it for now and see what others think.
Agree that we should include specification of roles. These are the only two roles that I can think of that every Workgroup would need. I'd suggest that Workgroups define additional roles as needed, recognizing that a role is a job that they want a group member to perform, not a set of skills.
I'll work on getting this info onto the page.