Help talk:Workgroup charter
The sections in this charter boilerplate are adapted from
- Thompson, L., Aranda, E., & Robbins, S.P. (2001). Tools for Teams Building effective teams in the workplace. University of Phoenix, Pearson Custom Publishing.
I have the text at home. It is excellent reading. --Nellie Deutsch 00:38, 6 August 2009 (UTC)
This boilerplate was created and is maintained by: WikiEducator Workgroups.
- [View source↑]
- [History↑]
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Approving charters | 6 | 16:04, 21 October 2009 |
| Delete navigator? | 7 | 15:07, 6 August 2009 |
| Suggestion to move Feedback & Suggestions to discussion threads | 1 | 14:46, 6 August 2009 |
| Archive of early discussion of proposed sections, July 5-10 | 0 | 14:14, 6 August 2009 |
| Archive of original discussion, Jul 5-15, leading to the creation of this boilerplate | 0 | 14:10, 6 August 2009 |
| Thoughts on: Securing equal committment & conflict management | 2 | 07:05, 31 July 2009 |
| Next steps | 1 | 07:05, 31 July 2009 |
| Specification of leadership style | 2 | 07:05, 31 July 2009 |
I'm thinking that the process is different for community wide workgroups and the more ad hoc working groups that form around OER content. I don't think the council needs to/should be involved in approving charters for ad hoc groups. Maybe all groups should evaluate and come to consensus on their own charter based on a set of criteria that they determine: is the charter complete?, does it adequately address all concerns/dissenting opinions?, are the outcomes achievable (with respect to resources, timeline)?... Also a group could request community review and comment. If so, a criteria for approval would be that they've addressed all review comments.
Community wide workgroups have extra steps for review and comment by the community and approval/endorsement by the community council. Wayne suggested in an older thread on establishing a workgroup that "Council's role should be to ensure that due transparent process has taken place rather than exercising value judgements on the charter." Council members would have an opportunity to review and comment during community review. The Council endorsement would be a last check to make sure the process has been followed.
So, in this document about generally using a charter, I suggest directing groups to develop a set of criteria to use for approving their own charter, maybe with some examples. The additional steps needed for community-wide workgroups can go in the workgroup guidelines.
Other thoughts?
Ad hoc work groups, OER content groups or project nodes in WE should have the freedom to operate as they see appropriate. I don't see any need for ad-hoc groups to use the workgroup guidelines and these may perhaps be counter productive and work against the principles of self-organisation in open wiki communities. There may be ad hoc groups that are looking for tips on how to operate or work in a wiki environment and they would be free to use these guidelines for their own projects.
Similarly, a specific project (eg externally funded project) may have different process and membership requirements to those we are suggesting for community-wide work groups. These groups should be free to organise themselves as they may require.
I firmly believe (and have seen) Governing boards fail when they start interfering in operations. Ultimately -- work groups (of any type) work in the realm of operations. For this reason, Council should not exercise value judgements on a charter but rather ensure that open and transparent development has occured.
With regards to the criteria for a proposed workgroup to become an "official" workgroup, I've posted a few thoughts. Bar the exceptions of workgroups which may result in financial, legal or technical dependencies -- I don't see that Council needs to approve a charter. In my view, Councils role is to foster due process -- the Charter guidelines provide a benchmark for due process. If these have been adhered to -- then Council will need to approve the policy proposals developed by the "official workgroups." If not, they will need to be deferred back to the community.
Cheers Wayne
On my first attempt (here) at using this boiler plate (the version with 2 tables of signatures) for this section, I found it confusing:
As people started signing, it looked like duplication with possible ambiguity as the same names appeared in both tables including WCC members and non-WCC members in the first table.
I assume the intention is to have two levels of approval for Community project charters:
- by workgroup members (before submission to WCC)
- by the WCC.
I added some wording to clarify (here).
Suggestion to avoid such confusion: a separate page for Community Workgroup submissions:
=Community Workgroups=
== [[WG X]] ==
<table of WCC approvers>
Status: submitted
== [[WG Y]] ==
<table of WCC approvers>
Status: approved
etc.
Then we would only need one table in the charter and the process would become: To submit your Community workgroup charter add it to the [[Community Workgroups]] page ..., and then, whenever a Community project charter is approved by WCC, its main (charter) page receives {{Approved_charter}}.
Hi Kim,
Thanks for the feedback on use of the charter boilerplate. Really valuable. I agree that the two table approach is confusing.
When I added it, I was thinking it would help us see who had participated at different points in the groups history: initial signup, approval of charter, and any other later approval steps. But I think it's too confusing. No workgroup has used it in this way. The approvals have all been recorded in a different spot.
Based on this feedback, I think the members section should be just a list of those who signed up to participate. The approval section (at the bottom) could suggest a process to include collecting member signatures to indicate approval. I'll revise to reflect this approach.
I'm also seeing that your understanding is that a workgroup's charter needs to be approved by council. WE Workgroups started with that premise, but later decided it's not necessary (and unnecessarily adds to bureaucracy) for most groups; council approval is needed only when there are financial, legal or technical dependencies. We tried to make that clear in the Formal constituion... section. Because the Admendments to open community governance policy workgroup was initiated as a result of a Council meeting, it seems right to include Council approval, although the fact that many Council members are participating, might make this unnecessary.
Does this make any sense? I'm very interested in your thoughts on how WE can improve the policy.
Alison
Ditto on the requirement for Council approval of workgroup charters.
The intention was to develop a policy that promotes transparency and adequate opportunities for participation by all WikiEducators and Council's role is that of stewardship -- ensuring good democratic governance.
Subsequently -- the workgroup policy has been designed to promote this democratic process and council approval of charters is not required. However - a work group is free to suggest council approval of the charter as one of the process steps and I agree with Alison that in this case -- Council approval makes sense.
Cheers Wayne
It seems to me that we should delete the navigator at the top of this page. Although Help:Workgroup charter is an output of the WE Workgroup, it seems like it should stand on its own. I'm just wondering how users who come upon this page and know nothing or little about the WE Workgroups workgroup will interpret the navigator.
But it does make sense for the navigator at WE Workgroups to include this page but then this page doesn't have the navigator, so it doesn't seem like it's connected. I don't have any experience in this kind of thing.
Thoughts? Other suggestions?
Hi Alison,
Having the boilerplate the Help:Namespace as a community resource is the right place in the wiki -- In its new location, I agree that the navigation template doesn't make sense anymore more on this page. I vote for deleting the navigation template on the top of the page.
We can also create an input box which will preload the boilerplate headings (with shortened version of the instructions -- and tips). We could lauch the input box from both the Boilerplate page in the help section and the policy page for workgroups. This will help folk get started and promote consistency across Workgroup charters.
Haven't checked yet -- did you Move the page (which keeps other pages which were linking to the Charter Boiler plate in tact with the move.) -- if not, well need to check the other workgroups who may have linked to this page and rectify the links.)
Under the references section I propose that for historical reasons -- we provide a link to the charter for developing the resource.
Looking good so far!
"We can also create an input box which will preload..."
- The input box idea to preload the charter boilerplate is a good idea. I saw the discussion on this in the proposed boilerplate style guide. Maybe the creation of the inputbox will be a job for WE Workgroups once we've completed everything currently on our plate.
"...did you Move the page..."
- I did *Move* the page and revised the more important links, e.g., in the Workgroup guidelines, to go directly to the help page. As you know I don't have much experience working in wikis (only the 1000 edits I've done here on WE; seems like a lot, but I still have a pretty narrow wiki-editing skillset and incomplete wiki concept map). I had to muster up some courage :P
"...provide a link to the charter for developing the resource."
- I had been thinking to create a statement of some sort to note that this boilerplate was created and is maintained by WE Workgroups. I'll put something in.
Yeah, I'm pretty happy with the result. The use of the boilerplate in the two workgroup start-ups provided great feedback.
Hi Alison,
We've been very fortunate in having at least three workgroups to trial the charter -- a great model for developing process guidelines.
I'm pretty impressed with your wiki skills --- 1000 edits represents a considerable amount of time and effort in WE. Yeah -- we'll look at the input box with preload text once we have the other stuff done. Its not too hard to set up -- perhaps I'll get a little free time over the weekend to take a peek at this :-)
Cheers Wayne
This is on a slight tangent...
If the intention of this page is to be used as a boilerplate then all the other information on it should be removed or placed in tags. The intent of a boilerplate is to be used with the {{subst:}} function which works just like template wiki syntax (including the use of inclusion tags inside the boilerplate), but instead takes all of the content and literally places or substitutes it into the page you want it in.
If you want it to be used as an inputbox preload, than nothing but exactly what you want in the content page should be in the boilerplate. Inclusion tags do not work with the inputbox extension, unfortunately, so that is not a solution.
My suggestion is that all of your rationale should be a part of the policy, or at this stage, the policy draft. This includes the resources and examples and such. If that sort of information is already in there, then I think the redundancy is unecessary. So in relation to this conversation, I agree that the nav box shouldn't go in the main page, but you could put it in the header of the talk page. That's what I did with the inputbox preload for the style guideline suggestions.
Jesse,
Thanks for your explanations (here and in the discussion on the proposed boilerplate style guide page). As you probably guessed, I didn't understand the prior discussions at the boilerplate style guide page on how a boilerplate can be used. I appreciate your taking the time to explain in more detail. I like the idea of putting the navigator and also some of the supporting info in the header on the talk page.
I'm glad I could help. You guys are doing a great job getting this policy set up!
The discussions on the main page in Feedback & Suggestions are resolved, so I think we should move these to discussion threads. Thoughts?
Discussion of earlier proposed sections[edit]
This information is very important:
Team Member Skill Inventory
(Areas individual members can contribute/want to develop) The WG needs to articulate how members will participate and the roles each will assume. [edit] Roles [edit] Team Leader
- Keeps team on task
- Monitors team projects
- Provides direction for team assignments
[edit] Communicator
- Coordinate meeting times and deadlines for assignments
- Maintains communication with team members
- Communicates with Administration
- Mediates and helps resolve conflicts
- Encourages and motivates team when times get tough.
...but I think this can be added once WGs work on their own charters.
I think that groups need to design what roles and responsibilities will exist in their workgroup, documenting them in the charter. I've studied the suggested template that Ben proposed, but don't see where the roles and responsibilities would be included. So, I've made some suggestions -- under leadership style (see discussion thread) and under a new heading called participants. Also, I think it's useful to include some examples. --Alison Snieckus 20:45, 10 July 2009 (UTC)
(
: I think we are mixing up two different tasks: a) the development of a template and b) the development of an actual charter. My intention here was to only develop a template with appropriate prompts that will guide others to create their own charter. I think we need to only work on the sections of the charter at this point. What do others think? What I had before this change was basically what I had in mind, sections that I feel include all the necessary aspects of a team charter.--Benjamin Stewart 15:51, 5 July 2009 (UTC))
- Please delete whatever you disagree with and add your own, Ben. --Nellie Deutsch 15:56, 5 July 2009 (UTC)
- I agree with Ben that this page should be a template with appropriate prompts. I'm a bit confused as to what was here before--as Ben indicates in statement above. Also, I'm not sure what this, "re:approval and signatures", section is. There are some good ideas down here.
- One of the ground rules *we* need to figure out is communication methods. I wonder if a talk subpage (satisfies requirement for email notification) with a specified method (satisfies need for a more organized discussion, maybe) would satisfy all of our needs. e.g., User:Jtneill/Talk. Thoughts? --Alison Snieckus 13:40, 6 July 2009 (UTC)
"Team Goals [edit] Potential Barriers
- Please delete whatever you disagree with and add your own, Ben. --Nellie Deutsch 15:56, 5 July 2009 (UTC)
Meeting schedule, locations, attendance expectations, agenda, assignment completion, communication methods, etc"
(: This is already included in the Ground rules section, no?--Benjamin Stewart 15:46, 5 July 2009 (UTC))
- Please delete whatever you disagree with and add your own, Ben. --Nellie Deutsch 15:56, 5 July 2009 (UTC)
"Approval of the content of the (working) charter."
(: When you say "(working) charter", are you referring to an external oversight committee of sorts? Is there any chance we can do an infobox for WGs that includes this "stamp of approval"?--Benjamin Stewart 15:13, 5 July 2009 (UTC))
- Please delete whatever you disagree with and add your own, Ben. --Nellie Deutsch 15:56, 5 July 2009 (UTC)
"Charters are signed by the members."
(: Can this be handled in the members section above? --Benjamin Stewart 15:13, 5 July 2009 (UTC))
- Will signing up to this WG (in this section) be a requirement?
- Will there need to be some note about how to treat members who aren't on this list but are participating (see example below)?
Note: This charter applies to all members participating in this WG (whether or not they appear in this section).
Archive of original discussion, Jul 5-15, leading to the creation of this boilerplate
Why this page[edit]
My aim was to start a team charter for this particular workgroup. --Nellie Deutsch 17:51, 5 July 2009 (UTC)
(: Ok, but will the changes take place here or in the workgroup page?--Benjamin Stewart 18:18, 5 July 2009 (UTC))
- Here. --Nellie Deutsch 18:25, 5 July 2009 (UTC)
(: Then should we create a place for a charter template? Or is this not desirable.--Benjamin Stewart 18:28, 5 July 2009 (UTC))
My preference is to have this page as a template for building a charter. Our home page would be *our* charter (exemplifying the implementation of this template), the guidelines page would link to this charter as information on how to create a charter.
Actually I wondered a while back whether the charter template/information page should be a top level page in WE because any group can choose to implement a charter and this would be a good resource. So if we can make this page apply to all work groups (not just the community-wide ones that we are working on), then we can create some top-level redirects to this page (team charter or work group charter) or move this to a top level page. Then if we want to specify certain aspects of the charter as optional or required for community wide workgroups, we can do so in the guidelines document. --Alison Snieckus 13:18, 6 July 2009 (UTC)
(: I agree with Alison.--Benjamin Stewart 18:10, 6 July 2009 (UTC))
(: I also agree with Alison.--Patricia 02:32, 15 July 2009 (UTC))
These two subheadings in the draft charter have had me thinking for the past couple of days. They don't seem to encapsulate the spirit and operations of open wiki communities.
Wiki's are primarily underpinned by a gifting culture -- workgroup participants are not "employees" of WikiEducator where the "employer" or project sponsor must ensure the productivity of its workers. There is also a fundamental difference between a wiki group and conventional workgroups in that there is a record / audit trail of every edit made. Participant's who sign up for a workgroup will quickly be noticed by their absence from participation -- for the whole WE community to see :-). Similarly, there may be many reasons for non-participation, eg travel, work or family commitments and I think we should refrain from judging participation or non-participation.
I think its better to work on the principles of acting in good faith - someone who signs up for a workgroup is volunteering time in good faith. The point is -- if members of a workgroup don't perform, that workgroup will not complete its specified tasks. In my books that's OK and in fact could become a motivation for future action. If there's little or no motivation for participation -- I'd argue that the workgroup task is not a priority for the community. Bottom line -- we don't loose anything by non-participation or inaction, but have everything to gain. Therefore, I propose that we drop the "Securing equal committment" proposal from the draft guidelines template.
Conflict management is important but I don't think that the work group charter is the right place for this. I think that its better for WikiEducator to develop generic policies for consensus, and civility and that all work groups and members will strive to working towards these ideals. Therefore I propose that we remove the conflict management subheading from the draft charter and focus energies on developing a consensus and/or civility policy for our community.
Thoughts?
Cheers Wayne
I agree that the securing equal commitment section should be dropped. Your rationale says it all. And I think we've got the issue covered from a number different perspectives already: member responsibilities, boundaries, and ground rules.
I've been thinking for awhile that we should create a page about consensus decision-making and how to use it -- an informational page. A consensus and/or civility policy is a step farther. Not sure about calling it a policy, consensus and civility when working together are certainly good practice and go along way toward creating the environment described in the WE values.
Yes, the title "conflict management" seems to give completely the wrong impression. I agree that it should be deleted. But in reviewing the charter template I don't think we've included a section for a group to specify how it will be make decisions. I think this is an important item that all working groups should consider. Maybe we should state that working groups are strongly encouraged to use the consensus decision-making process (with a link to the info page). I think this would go in the ground rules section.
Interesting to think about how behaviors and expectations are different in this environment.
Alison
Hi everyone,
This template is really coming along. Two WE Workgroups have tried it out (WE Administrators and Style guidelines), and we've made some improvements to the template as a result.
I suggest the following next steps:
- Move the page to a page in the WikiEducator namespace. Suggestions for where/what to call it, noting that this template is for use by any and all WE groups and teams, not just the Official WE Workgroups?
- Post to the main WE list requesting community-wide comment and review (one of the steps that we are considering for the WE Workgroups guidelines.
- Revise our WE Workgroups charter to correspond with this template.
Please share your thoughts on these.
Best, Alison
I'm going to go ahead with moving this page. I just saw a discussion thread started by Jesse Groppi in a proposed guideline onboilerplates where she suggests putting this page (as an example of a boilerplate) in the Help namespace. I hadn't thought of this as an option before, but it seems right. I will name it Help:Workgroup charter.
I don't see the difference between leader and facilitator as it relates to WE workgroups. Rather than suggest a distinction, maybe this section should be about defining the leadership role and provide an example. Also, I'd rename it as Leadership Role. Here's suggested text.
"Leadership Role
Indicate whether this workgroup will have a leader/facilitator and provide responsibilities for this leadership role. For example,
The XX workgroup is led by a facilitator. The facilitator's responsbilities are:
- Keep team on task
- Monitor team projects
- Provide direction for team assignments"
Any other opinions on this?
Personally --- I don't think we need to be too worried about what labels we use for this role: leader, co-convenor, facilitator, instigator ;-) etc. The trouble is that different leadership models and theories attach different meanings to these and other labels. Ideally we strive for consensus and collaboration. Some folk are natural leaders / facilitators. Each work group will have its own dynamic -- that's the open wiki model. If the charter compartmentalises too much -- we may constrain innovation and participation. My own feeling is to be a little more own and flexible on the use of labels and roles.
The charter template is intended to be a guideline -- not a policy. So we can be a little more relaxed about nomenclature -- ultimately work groups which don't bring together the right ingredients, will not complete their specified tasks -- and that's OK.
To be fair -- the initial Charter template guidelines were not developed for wiki communities (to the best of my knowledge), so we have a little liberty to be flexible :-)
Cheers
I totally agree. In fact, I spent some time reading about shared/collective leadership last night. I had no idea that such a style existed. I decided last night that I'd like to redo the leadership style section to include the shared leadership option -- I was too tired to attempt it so I left a note to remind myself. I think I'll lay out a few options for groups to consider, with the upshot that there's lots of flexibility here.
I agree on the idea that many actions are self-limiting, so no need to require exact adherence to a particular process.
I've had the same thoughts about how well a charter template that likely originated in a face-to-face market-driven business world, will work out for groups of distributed volunteers working in a directly collaborative environment, as is the case in a global wiki. It's been really helpful to have the Administrators workgroup trying things out.
