Talk:Workgroup:WikiEducator Workgroups/Guidelines
Note that this guidelines page was created subsequent to a decision to use the main Workgroup:WikiEducator Workgroups page to house the group's charter and following much significant discussion of how to constitute WE Workgroups. These early discussions are available on WE Workgroups' talk page.
- [View source↑]
- [History↑]
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Feedback and comments welcome | 3 | 12:22, 24 October 2009 |
| Rethinking definition of WikiEducator | 4 | 14:10, 30 September 2009 |
| List of Existing Workgroups? | 4 | 03:18, 30 September 2009 |
| Policy approved by Council -- next steps? | 1 | 14:52, 21 September 2009 |
| Questioning the use of 'Official' | 11 | 07:23, 20 September 2009 |
| What are the steps for activating a policy... | 5 | 18:45, 7 September 2009 |
| Finalising the policy | 7 | 14:36, 30 August 2009 |
| Amending a charter | 4 | 16:08, 27 August 2009 |
| Questions regarding formation of technology related groups | 3 | 09:30, 27 August 2009 |
| Suggestion for workgroup support | 1 | 15:25, 6 August 2009 |
| Archive of initial thoughts on outcomes of this group | 0 | 14:01, 31 July 2009 |
| Determining the shift from proposed to official workgroup | 4 | 13:41, 31 July 2009 |
| Guidelines as part of charter | 1 | 14:26, 6 July 2009 |
- "including a minimum of 30 calendar days for discussion" - should this match "minimum period of 15 calendar days" on the Workgroups Guidelines page?
Good catch, Kim! In the initiating a workgroup section the step following create a charter says:
5. Post to the main WikiEducator list providing a concise summary of the Workgroup and requesting community review and comment on the Workgroup charter, including a minimum of 30 calendar days for discussion with clearly stated deadline for comments. Collect the comments and suggestions in a section of the charter or corresponding talk page.
and then later in the formal constitution section the following is stated as a requirement:
3. A minimum period of 15 calendar days was provided from the date of the community announcement on the WikiEducator list before approvals of the charter by signed participants of the Workgroup.
I'd say one of these needs to change. I suggest changing the latter to be 30 calendar days.
Any other opinions?
The following definition is included in the definitions section:
- WikiEducator refers to any registered user of the WikiEducator websites.
I like the simplicity of this, but I'm now wondering if in practice, it could be confusing. The result is two definitions for WikiEducator: 1) the website (and by implication the community) and 2) the registered users. I think this duality of meaning could result in confusion in some situations. Maybe we shouldn't encourage the use of WikiEducator to refer to a user. I suggest the following revision:
- WikiEducator member refers to any registered user of the WikiEducator websites.
thereby distinguishing a member from someone who is just viewing pages.
Hi Alison,
I see the point. For policy documents I think its important to be clear and avoid potential ambiguity. I think WikiEducator member addresses the problem.
On a lighter vein -- in general usage of the term the confusion between the site and user is quite appropriate -- the user and technology conflate and become one. Perhaps over time we will adopt a de facto convention eg WikiEducator to refer to the site and Wikieducator (small "e") to refer to registered users in general posts.
However -- in the policy I think we need to be clear and you have my vote for WikiEducator member.
Cheers
I like the way that WikiEducator means website and community in one. Great idea to refer to members with small 'e' -- Wikieducators! I will definitely use this in informal settings. Let's see if it takes hold.
And in the meantime, we'll use WikiEducator member in the policy documents to ensure clarity. I'll make the changes (and change back my initial edits on this topic in the style guidelines policy).
A third class could be "wiki-educator" (hyphen) when referring to people who also use Wikiversity and other wiki-based platforms.
Kim,
Great thought and what a coincidence that you post this today. I an entry for WikiEducator in the WikiEducator glossary last night and remembered that this post had some interesting nuance that we could put in the definition, but wasn't sure where to start looking for it.
And then today it shows up in my "There are new messages for you" page, with another good thought to add to the definition.
Thanks, Alison
Is there one? (i.e. so that one can first check that an existing work group is not already working on the policy/guideline in mind)
The WikiEducator:Community_Portal includes a listing of active Community Workgroups, also we've created Category:Workgroups that provides a link to all Workgroups. (I noticed that there is a Workgroup on the active list that's not in the category. I will go add it.)
Great! Thanks :-).
Another thought: is it possible to search the Workgroup: namespace only? It should be possible by unchecking "(Main)" and checking "Workgroup" at the foot of a search result page (such as this]), but the "Workgroup" namespace is not listed?
Agreed. I'm a beginner at all of this. Here's how WP explains their namespaces:
A Wikipedia namespace is a set of Wikipedia pages whose names begin with a particular prefix recognized by the MediaWiki software (followed by a colon), or in the case of the main namespace have no such prefix.
So, could it be that the Workgroup: namespace is not listed in the search box because it's not being recognized by MediaWiki?? There are other pages beginning with a phrase followed by a colon that are not listed in the search box (e.g., LearningDesign). How do we decide what namespaces to maintain?
Workgroup:Technology_policy lists one of their objectives as: "Propose procedures for Community-initiated suggestions for technology related decisions." How to handle namespaces is probably one of these procedures. Not sure how a WE member would bring this up to the group.
In order for a prefix (xxxx:) to be recognised by the software, it needs to be added to the server file, and thus it becomes a namespace that is searchable, and pages are filed automatically into the namespace when created with a title that starts with the prefix. "Workgroup:" is actually what would be called a "pseudo-namespace" which means it resembles a namespace and provides the identification properties a member would recognise, however it does not have the functionality. See this definition by MediaWiki.
Pages with the "Workgroup:" prefix are actually in the main namespace (the one without a prefix), and "Workgroup:" is actually part of the title. This means that methods of dropping the namespace from being displayed or used in sort keys (such as a preceding colon or a vertical bar) do not work, and one has to manually indicate a sort key or display text in order to do so. It also means that in order to search only among pages that are "in" the pseudo-namespace, one should do something like include "Workgroup:" in the search parameters.
Congratulations to WE Workgroups, our Policy for Community Workgroups was approved by Council on 13 September 2009.
Now we can refer to our very own policy to determine next steps: instructions for activating a new policy.
But before we do that, I suggest we address the new comments under "Questioning the use of Official":
- have we been overzealous in our policy making; is the policy more prescriptive than it needs to be?
- should we try revising with the goal of moving the tone from prescriptive to encouraging?
- does the policy require steps that could be included as recommended, or even left out altogether?
- should we implement a recognition program for policies that make the extra effort to become community-wide WE policies?
Thoughts on how we can address Kim's and Jesse's comments? Any thing else we should add into our "next steps" pile?
I've been thinking about the policy vs. guideline distinction (just read the almost all of the discussion, and there's a lot, on this topic on the WP policies and guidelines discussion page -- lots of issues I'd not considered).
I wonder if what we've created combines policy statements (i.e., members must do this) with guidelines for how to get it done. So a solution would be to create a strict (in the sense that nothing else is included) policy statement with a link to a guidelines or help page for suggestions on how to do it.
Just a thought.
I've been thinking about what to call the community-wide WE workgroups. I'm not crazy about the term Official. I'm not sure why, really. I've been thinking this for awhile (especially noting that the term Official has not caught on with the other start-up WE Workgroups). So, I'm wondering if we should just call them what you all called them at first, before I started asking questions way back when -- see title of this group WikiEducator Workgroup(s) (it's a name so both words are capitalized) -- and then explain/clarify what WE Workgroups are at every available opportunity. We could use the new Template:Whatis on every WE Workgroup charter to link to the definition that we provide in the guidelines. I don't want to belabor the naming of things, but thought if others are thinking similarly, we should change now while we're still at the beginning of the road. Other thoughts on this?
Hi Alison,
I'm not too happy about the term "Official" as well -- it doesn't fit the way we work in Wikieducator. This came about from Ben's valuable contributions pertaining to "general" workgroups for content and or individual projects. The point is, the policy is not intended to regulate "general workgroups" -- so we need some way to distinguish these.
What about:
- Community workgroups --- as a replacement for "Official" WikiEducator Workgroups and
- Project workgroup --- as a replacement for "General" workgroup?
We have a definition section in the proposed guidelines where we can define clearly what we mean. The fact that there has been considerable discussion on this point -- suggests that we need to find a clear way of identifying these differences.
Cheers
Alison,
I'm going to go ahead and make the change to the terminology as proposed above -- -its a wiki, we can always refine the draft further.
Cheers
After the event:
This is a useful exercise which may result in some excellent guidelines. I would hesitate to make it a mandatory process even for Community workgroups. More agile, organic, spontaneous community processes (e.g. via a collection of self-organising projects on WE) may result in policies/ approaches adopted more widely later (perhaps as de facto standard practices before they become "approved policy").
Would it make sense rather (or in addition) to institute a WE Community process to highlight and "approve" emerging guidelines and policies? The resulting pages may be tagged (with attribution and a gold "WE Approved Policy/Guideline star") rewarding the innovators (of the associated projects) and those who took the extra trouble to elevate it to WE Community level.
All the thinking so far on this page would become part of the valuation/"approval" process, rather than a prescriptive process.
I could imagine something like this happening with the Language Policy - many projects involving multiple languages, as we go along we learn and adapt each others' good ideas, the best of which rise to the top and become standard practices.
Regarding consensus, check out the following approach to decision making in the Apache project: Decision Making (click and scroll down). That has worked well for a very prominent software development initiative with multiple projects. For WE, a libre knowledge community of communities with multiple projects, what actually happens is likely to be (and should be IMHO) at least as "lazy".
Thanks for your thoughts on this. I think you are right that making this policy mandatory could diminish the desire of the community to be spontaneous and self-organizing and thereby less likely to work towards the betterment of the community, which is obviously not the intent. I wonder if there are examples of this effect already.
In my mind, we need to balance the need to be spontaneous with providing a mechanism and support for members who recognize a need, but don't know where to begin to start working to address it. I think there are a lot of members like me who have no previous experience working in an open, geographically disperse, online community. I think helping people to get involved is important to the success of WikiEducator. And I can see how the idea of mandatory could get in the way.
I like your suggestion for creating a mechanism to recognize emerging guidelines and policies, with the idea of encouraging their development into community-wide WE guidelines/policy.
We could revise the mandator-iness in this policy into steps for moving guidelines or policy to apply community-wide.
Also, I think WE need to integrate a page discussing what policy and guidelines are, how different communities within the larger WE community can have "local" policy and how policy/guidelines get made with the Policy on Community Workgroups. I've noticed this WE policy page.
Thanks so much for the link to the Apache project. I have only a cursory understanding of what this project is about (I think I heard someone once use Apache as an example of a really successful open source software development effort), so I would never know to go looking for their organizational process. I see what you mean by 'lazy'. Is it fair to say that it's a consensus of those interested? If you're interested you pay attention and participate, if not, you implicitly trust that others will do their best. I also like their term do-ocracy. I wonder how do-ocracy will play out in WE.
Good ideas. I'm interested to see what others think about moving this policy to a less prescriptive process.
Alison,
I have refrained from making any comments regarding this workgroup, though I have been watching it, because I'm still trying to wrap my head around the idea of a globally recognised foundation and a wiki working together in this way. I'm not really familiar with Wikipedia's working relationship with the Wikimedia Foundation, but I get the impression that WE's working relationship with the foundation is one of symbiosis, perhaps more so than WMF and WP. Without WE, the foundation doesn't work. Do I have the right idea?
Hi Jesse,
Good questions. I'm certainly not the most capable at clarifying, but I can say that I have a similar understanding of the relationship. Although I think there is more to the Foundation than WE. My reading suggests that WE is the main mechanism for achieving the goals and vision of OERF. OERF's About page provides the bigger picture of the foundation and how WE fits in. Note that there is a WE.com entity that is a for profit initiative (I think).
I expect Wayne will chime in here at some point and help us both come to a better understanding as to the relationship.
Hi Jesse,
Symbiosis is a good description of the working relationship between the OER Foundation and WikiEducator.
I should also point out that WE has a different organisational history when compared to WP and WMF.
WE was originally administered under the auspices of an international agency i.e. the Commonwealth of Learning (an intergovernmental agency established by the Commonwealth heads of Government.) All operations and support were centrally funded by the Commonwealth of Learning. I must commend COL for its commitment to a community governance model for WikiEducator thus enabling the project to evolve as a community of association -- a community of educators working together on OER projects without interference in the community governance of the project. This is unusual in the world of international agencies and attests to COL's commitment to listen and respond to the voices of the communities it serves. The growth in Wikieducator as an international project had resulted in a number of difficult challenges. For example, COL is funded by Commonwealth governments, and therefore it was becoming increasingly difficult to justify expenditure supporting WE initiatives for members from non-commonwealth countries. Software development necessary to improve they way we work could not be justifiably be funded by COL as this fell outside the agencies remit. Moreover, it was not possible to raise donor funds for WE as the community has no legal status. The domain names of WikiEducator have been transferred to the OER Foundation an independent non-profit registered for charitable education purposes.
Symbiosis is a good description of the relationship between WE and the OERF. WE provides a solid foundation for the OERF to raise donor funding and membership contributions to support the work of WE. Similarly -- OERF is the sole funder of WE paying for the server infrastructure, training workshops etc. The OERF respects the autonomy of WE and is required to operate within the policies established by the community. For example, there are no allocated seats on Council for the OERF nor is there a requirement in the constitution of the OERF to have WE members on its board of directors.
OERF has a wider remit than WE -- and this is healthy situation. OERF has the flexibility to widen its sphere of operations regarding funding models etc, without compromising the core values of the WE community. WE has the advantage of a dedicated funder --- and the more success WE achieves, the greater the returns will be for our community. (Remember OERF is a non-profit, and all surplus funds are reinvested back into OER and WE.)
OERF subscribes to open philanthropy which means all planning documentation, funding proposals etc are developed openly and transparently in the wiki.
This is the model we have, and its worked well for WE to date, taking into account that the majority of WikiEducators are working within the formal education sector. Speaking candidly, the funding models and organisational structures are more appropriate for education institutions who are traditionally more conservative.
I absolutely agree with your comments about mandatory processes. In the wiki/open source communities I come from, the one thing I have learned is that the large majority of members are incredibly fickle. I truly admire my fellow teachers for their passion for education, but I don't think professionals are immune to the fickle phenomenon. To date, most of the precedent is found in the computer and software professions, but that precedent, shown by the Mozilla foundation, the World of Warcraft addon communities, and others, proves that for every successful project, there are ten that go unfinished. The idea has been that "friction" in the environment contributes to this behaviour. The environment includes policy and collaborative situations.
This article on meta wiki provides a good example of the woes of over zealous policy making. The example talks about the result of someone screwing up, but I've also seen this sort of thing happen for more selfish reasons. Someone gets offended because they were not included, or didn't get what they wanted, and a suggest a process which makes the situation more favourable to the individual. The group often takes it up as being more "fair", rather than beneficial to the situation.
I'll admit, I'm a bit colder to emotional situations, an not always successful at attending to a team's emotional needs, but I tend to look at this sort of thing as a matter of "keeping one's eye on the ball". This is perhaps a more American idiom meaning that the utmost priority must remain utmost, no matter the situation, otherwise that priority is devalued, and the results will not be equivalent to the team's potential. WE's "ball" is providing free education resources to the world, which is done at the ground level by authoring content.
Policy aside, I think you will be very interested in the style guide workgroup. I think these are a good example of what this community can achieve with an Apache project-style "do-ocracy" (I really love that word!). I'd like to hear your opinions on the process we've devised for both the workgroup and the guidelines. In fact, we have discussed a guideline that encompasses your language policy suggestions.
once it's been endorsed by Council. I think active policies should be moved to the WE namespace, keeping the link from the Workgroup's navigator. Is there anything else that a Workgroup should do to activate a policy/guidelines? Maybe we need another heading in our WE Workgroups policy: "Activating a policy or set of guidelines". Or maybe we want to use the phrase "Implementing a policy..."
Is it the 11th hour yet?
Yeah -- good point. I was also thinking that once a policy has been approved -- it should be moved into the WE namespace as an active policy and possibly protected from editing?
Still time for comments :-)
Thanks for all you help for a job well done. I think this is an exemplary policy showing how open communities can collaborate!
I'm not sure if we should protect from editing (at least just yet). It'd be interesting to see if anyone contributes -- are there small improvements that could be made to the policy that wouldn't need to be widely vetted? Not sure.
Is there a category page for listing WE policies? Should guidelines and policies go in the same category?
Should we add a section after "Making a submission..." called "Implementing policy and guidelines" and say just a wee bit about what to do once a policy or guideline is approved?
Hi Alison,
I see any major need to to protect the page once approved -- we'll have this on our watch list :-)
Currently -- we don't have a category for "Approved policies" so we'll need to implement this. Good suggestions.
I like the idea for a section in "implementing policy guidelines".
Amazing how the iterative process improves quality!
To iterate once more on this, I added some new bits to the document to reflect the implementation stage, but quickly realized that I don't know what Council will do to communicate ratification/approval of a process, so I'm not that sure what the implementation steps should be.
I ended up adding two more sections,
- "Response from Council" under "Making a submission"
- "Implementing new policy and guidelines" as a new section to reflect actions that the Community Workgroup needs to take to activate the policy.
Although I set it up as two pieces, there are certainly other ways of doing this. See what you think.
In suggesting that the policy be moved to WE namespace page, what should we do with the Appendix (listing suggestions for future work)? Should the Appendix stay with the Workgroup? Or maybe the Appendix section should go in the header section of the new policy page's talk page? Probably related to how WE want to handle changes to approved policy (see note below).
Also, I propose the name Category:WikiEducator policies and guidelines. I'm not sure the ramifications of combining these two in one category (something like style guidelines would be listed as a set rather than each one separately), but figure we can delineate later if needed.
And here are a few more items that we need (related to policy and guidelines). I vote for tackling these in the next phase of work, assuming it's WE Workgroups that should work on these:
- template for approved policies that marks the document approved, links to overview page on policy and guidelines, and categorizes page into WE policy and guideline category.
- main page describing WE policy and guidelines
- statement on how to revise policies (I was thinking that Workgroups would do this, but maybe we want a more open "propose, talk, revise" process that anyone can participate in at any point) -- I think we should discuss this on the main list.
Hi Alison,
I've read the two new sections -- makes good sense to me. I've added a bullet about effective date.
We can sort out the detail on the Category -- possibly implementing a sub-category solution.
I agree that the extra bullets should be tackled in the next phase of work.
Again -- congratulations to the team on a job well done!
I've reviewed the policy and completed a draft for the missing sections. In summary:
- Made a few minor consistency edits
- Changed the Technical workgroup requirement to 3 members including a sys admin plus the requirement to obtain a consensus recommendation from the full WikiEd Tech group before submission of a technical related policy
- Drafted a process for substantive revisions
- Drafted a section for evaluating & reporting on WorkGroup activities
Now off to tackle a draft report.
The changes and new sections look great. I made some wording revisions for style and clarity. Also, I wasn't sure at which step the Workgroup would make the revisions to the current charter, so I added this as a step.
I only had time for a quick review of the evaluating and reporting section, but I'm wondering if we should recommend reports on a regular basis along with requiring them to accompany a submission to Council. Once a Workgroup has drafted a policy or a set of guidelines, I can envision their continued work in implementing and evaluating the policy/guidelines, although they may not have any further outputs to submit to Council. Might the group prepare a report for each time the Council meets? On some other regular basis? Just some initial thoughts.
Hi Alison,
Thanks for your efforts in tidying the revisions -- they're really looking good :-)
mmmm -- Speaking personally -- I'm not a bureaucrat in the sense of requiring ongoing reports. If it ain't broke no need to fix it. I think there should be a requirement for a work group to prepare a report for Council when a new policy or amendment or revision is proposed, following the procedures we're recommending for workgroups. However, if there is no change or no amendments to existing policies, I don't see the need for regular reporting back to council. Only when a change or addition to policy is required.
In reality -- the wiki provides a detailed history of all activity and if any member of the WE community want to know what's going on --- they can check the history pages at any time. I see the report as a resource to provide a quick overview and reference point of activities pertaining to workgroups and corresponding policy changes, for folk who have not been directly involved in the workgroup -- rather than a hierarchical reporting requirement in the traditional sense.
You've got me thinking -- we don't have anything in the policy regarding how to dissolve a Workgroup once it has completed its task. Once the Workgroup objectives have been achieved there should be a formal dissolution of the group.
Thoughts?
I totally agree that we don't want to just make regular reports a requirement. I see that my post suggests that. I think I suggested a solution to a problem and failed to adequately describe the problem to which I was offering a solution (it was late and I was rushing).
The problem to be solved is of a piece with your comment about formal dissolution of a Workgroup: how do Workgroups operate after the initial policy is submitted and approved. If policies and guidelines are "living documents in the sense that they get amended, refined and improved as community experience grows." (and I completely agree with you on this), then maybe all Workgroups continue in some fashion. We don't really say in the definition of Community Workgroups that they will have continuing work following the development of policy and guidelines, but I think Workgroups may be called on to implement the policy, provide guidance for a process and/or provide the stewardship of ever-evolving aspects of WikiEducator (e.g., the style guideline workgroup will be working on the style guidelines and their implementation and later revision long after the policy is endorsed by Council; the learning design workgroup is charged with the stewardship of the pedagogical templates, a resource that will likely evolve as WE evolves). But even if a Workgroup's work ends at some point, I think the group would exist in hiatus until needed, at which point WE would reconstitute it.
[Along these lines, a few weeks ago I added a row in the beginning table in the policy indicating that WE Workgroups created the policy and is charged with maintaining it. I added a similar row in the beginning table in the style guidelines policy.]
I wonder if we should refocus the report section, now titled "Evaluating Workgroups", with a new title: "Making a submission to Council" and be very explicit about what should be submitted and how to do it and leave the rest for later, when we see the kinds of Workgroups that exist and what their needs are in their continued work. I don't think any of the existing groups will be seriously impacted by leaving this for later.
Hopefully I've better communicated my thinking on this.
Hi Alison --
You have communicated very clearly :-) Good points and thanks for taking the time to clarify the points.
I think closure and dissolution of an workgroup that has delivered on the outputs is important. Wiki stress can be a challenge, yet at the same time I see the challenges and opportunities for more permanent workgroups. Clearly the style guidelines and Learning design workgroups are ongoing, whereas others will have a discernible point for dissolution once the tasks have been completed. We also need to be clear to prospective Workgroup participants in terms of what is expected in terms of the time commitments they are volunteering. This also raises the interesting question of resigning from a workgroup, and what happens when a resignation results in the workgroup falling under the required number of participants.
mmmm --- thoughts:
- Perhaps we need a further categorisation between permanent and "temporary" (not the right word) work groups (we could cover this in the definitions section and refer to relevant points in the body of the policy.)
- Under permanent workgroups -- we need to be clear that the workgroup must continue to remain a valid workgroup in terms of the minimum requirements.
- In the case of workgroups that have clearly defined outcomes and these have been achieved as in a policy that is approved and moved to the WE namespace - that the workgroup dissolves. We can think about procedures that when a workgroup is reconstituted for revisions that there is a requirement to contact original workgroup participants with an invitation to join. I think its important to have closure -- because peoples lives and circumstances change.
- We should develop a few guidelines on resignations from workgroups and what needs to be done if the workgroup doesn't maintain minimum required members.
"Making a submission to Council" is a much better heading as it explains what it is :-) I vote for changing the heading.
It seemed like we needed to say something specific about exactly how to make a submission to Council, so I added a bit before the Workgroup report write-up to describe what I thought the steps are. I feel like I shouldn't be making such substantial changes at this point, but I guess I feel more strongly that we should say specifically what to do.
Also I made a few changes in the report section. Hopefully nothing that changes the meaning.
Don't hesitate to revert these changes if you think we should submit what we said was the final draft.
I guess we can continue the conversation of what happens next for a Workgroup in our next round of work.
Alison
I've posted a note to the list advising on the 3rd and final draft of the policy and that the report is available.
I've requested final comments by 17:00 GMT 30 August 2009 -- which will give us time to prepare the final submission for the Council meeting.
Thanks all for your help in getting this job completed on time.
Cheers Wayne
The fact that the Administrators workgroup is considering amending its charter to extend its work beyond that first envisioned, suggested to me that we should include in the Community Workgroup policy a recognition of this need and a suggested process for doing so. My suggestion is to put this in the "Supporting Community Workgroups" section, rather than the "Establishing..." section, which we are focused on now.
This is the advantage of hindsight and experience.
What about a new subsection along the lines of "substantive charter amendments" -- That is what to do when a substantive change in the project plan or objectives occurs.
Ultimately the intent of substantive amendments is to prioritise quality above mechanistic adherence to deadlines or other requirements. I think it would be good to develop a few procedural guidelines for this scenario.
Cheers Wayne
I've been thinking for awhile that we should portion our work on this policy into two phases: 1st phase determines policy and guidelines for initiating workgroups, 2nd phase determines policy, guidelines and support mechanisms for functioning Community Workgroups. I think the charter amendment process fits in the 2nd phase. I've been messing around with sections that could be included in this 2nd part, now titled "Community Workgroups at work". I added a section where we could list some guidelines for amending a charter. I'm reluctant to propose guidelines for this process now, given our upcoming experience with WE Administrators could well inform our thinking.
I feel a little bit like I'm pushing off what could be done now until later, but I like the idea that WE Workgroups has focused on developing what appears right now to be a good working process for initiating Community workgroups. There's not been much discussion from other WE members on the policy details, I can only hope that many have have checked it out and were happy with the process as written.
Policies should be living documents in the sense that they get amended, refined and improved as community experience grows.
So it's fitting to hold off on drafting sections where we have limited experience.
"Community Workgroups at work" is a good title -- the structure makes sense.
Thinking practically -- given that this is a policy document, I think that it is wise not to have uncompleted headings, so that we can differentiate work in progress from the actual policy. I propose adding an Appendix section to the policy where we can have a subsection on proposed subsections / drafts awaiting ratification -- this way we separate the draft sections from the actual policy.
I'll have a bash at drafting something for substantive changes for consideration of the current policy approval process.
Using an Appendix to include ideas for future improvement of a policy document works rather well. I was looking for something to distinguish the sections. This takes care of it.
Well it looks like we have a proposal for amending a charter. Now that you've got it going, I see the wisdom of doing it now. I think it will work out better to have something drafted that WE Administrators can try out. With the proposed steps provided, there's much less chance that the group will get bogged in the revision process.
I'll comment further in response to your "finalisation" thread.
I have a few suggestions/questions regarding the following criteria from the "Formal constitution..." section:
"In the case of a Workgroup that will result in technological dependencies or technology security issues, two thirds of the members of the WikiEducator Technical Group including at least one of our Server Administrators MUST be signed up as participants of the workgroup. Technology workgroup members have the right to table a minority position for consideration by Council in the event where consensus cannot be achieved."
- I suggest adding a link to the main page of the WE Technical Group. I would have done this, but I couldn't find it, only the WE Technical Google group.
- I suggest adding a link to the page listing the Server Administrators.
- I wonder if instead of the two-thirds criteria, "two-thirds of the members of the WE Technical Group...must be signed as participants....", it would be better to make the criteria a minimum number. If the WE Technical Group were to grow in size, two-thirds could become unwieldy and burdensome, which could bog down the process. To keep the group as a mix of technical and non-technical, we'd need to add a minimum number for non Tech group members. OR, maybe we want to say that two-thirds of the Community Workgroup must be members of the WE Technical Group, including at least one Server Administrator. Actually I'm still in favor of making this a minimum number, in either case.
Hi Alison,
Sorry I missed this post.
You're right the WikiEd Tech group should develop a page on the wiki :-).
They're typically too busy looking after the health and safety of our servers. In the mean time you can link to the WE tech group: http://groups.google.com/group/wikieducator-tech
Will get this onto the to-do list.
I'm inclined to agree with your point about 2/3 thirds of the WE Technical Group. While currently small at the moment, it could grow. So I propose that we go with a minimum of three with at least one Server Admin required.
I'll post an invite to the Tech group to take a look at the proposal as well.
Cheers
Perhaps just a couple of tech group members would be useful in a workgroup to provide advice (and suggest alternative solutions?). If the output of a workgroup requires a change in the server configuration it will presumably require consensus among (all) the tech folk... and if necessary those that weren't active participants can review the discussions of the workgroup.
We may want to consider developing a check list detailing all the steps and requirements for a community workgroup, available in both Wiki and downloadable pdf format.
Thoughts?
Good idea.
I've started to think that we should have a multi-phase approach to this group's work. The current phase is focused on figuring out the process for initiating Community Workgroups. The next phase could focus on what we need to support Community Workgroups. Of course, a checklist detailing the initiation steps could go in either phase. Your suggestion just got me thinking about a second phase focused on support.
To save time in tracing the development of the policy -- Herewith the initial thoughts on the purpose for the guidelines, prior to the current statement of purpose:
- Initial thoughts -- I think the main purpose of the guidelines for workgroups is:
- To help WikiEducators establish workgroups
- To know where to list and communicate the existence of new workgroups
- To know the difference between a Community-wide workgroup versus individual project collaboration. --Wayne Mackintosh 00:57, 1 June 2009 (UTC)
- To work alongside established parameters within WE in an effective, well organised and user-friendly fashion
- To provide good quality support systems and maintain a good oversight of active working groups' and their work--Patricia 02:20, 15 July 2009 (UTC)
- Other thoughts, ideas ...
Herewith the link to the revision, prior to the current formulation of the purpose:
http://wikieducator.org/index.php?title=Workgroup:WikiEducator_Workgroups/Guidelines&oldid=404827
Hi been doing a little thinking regarding recognition of official workgroups with reference to the current version of the guidlines.
Currently we are saying:
5. Submit the charter to the Council for evaluation and endorsement. (Council's role is to ...)
6. Post to the main WE list providing a concise summary of the Workgroup and requesting community review and comment on the Workgroup charter. Collect the comments and suggestions in a section of the charter.
7 Address each of the comments and suggestions and make amendments as needed to the Workgroup charter. Resubmit the charter to Council for its endorsement to begin work. (Council's role is to ensure that the amended charter adequately addresses the WE community's comments.)
8 With Council's endorsement, the Workgroup moves from a Proposed Workgroup to an Official WikiEducator Workgroup.
Thinking practically, assuming Council do not meet more than twice a year, the step to require Council endorsement of the Charter could delay progress and community ownership of community-wide initiatives. I see Council's role as the custodian of democratic and transparent process, and the vehicle for approving official policies. Therefore, I don't see the need for Council to approve the charter before the workgroup commences its work. Ultimately with regards to the approval of a policy -- Council will check to see that the guidelines have been followed -- if not then the policy proposal would be deferred back to the workgroup. So as long as we have clear criteria for an official workgroup -- then this step would not need Council approval.
So for example, the criteria for an official workgroup could be:
- Procedures for proposing and constituting a work group have been followed.
- Minimum of three WikiEducators required to from an Official Workgroup.
- Minimum period of 10 working days from the date of the community announcement of the Workgroup charter required before final acceptance
- Final acceptance of the Charter by majority approval of workgroup members listed on the date of acceptance
- In the case of technology related Workgroups, the majority of the WikiEd Tech team must be participating members
Exceptions requiring Council approval of the charter prior to commencement of activities:
- Workgroups which have legal implications for the WikiEducator community
- Workgroups that require central funding for their operation or may impact on future funding requirements of the WikiEducator community
- Workgroups relating to changes in the existing governance model of the Community.
I propose that we amend the draft for approving official workgroups along these lines.
Cheers W
Agreed. We have indicated that this process for creating and operating Official Workgroups be without undue steps and red-tape that could delay the process and undermine motivation. If we require that charters be vetted in the community, Council members can contribute as needed. The extra check of a group's charter by Council seems unnecessary, except in the instances you list.
Good thoughts.
I would like to see the council function as a workgroup and decide on the procedures for the workgroups.
Yeah -- it would be great if the Council could operate as an ongoing workgroup.
In some respects, at least at a theoretical level this is possible in that every Council member can sign up and participate in any of WE's workgroups.
The difficulty in the real world is that we're not going to get all Council members to be available at the same time nor will a model where Council participates in everything be able to scale. The ability to support and encourage community members to collaborate in developing our processes, policies etc. is a huge asset for WE.
Similarly -- I suspect that Council will from time to time constitute workgroups for specific purposes of council -- and that's a good thing. These guidelines will also contribute to supporting Council members with less experience in the workgroup process -- while at the same time promoting transparent and participatory practice.
Back to the question -- Are you for or against the proposed criteria for the constitution of an official workgroup suggested above?
As we've not received any disapprovals of the proposed criteria for constituting an official workgroup from the participants of this group, I'm going to incorporate these suggestions into the policy draft.
We requested feedback on these criteria as per my email to workgroup participants on 25 July, requesting feedback by 30 July 2009. I include a copy of the email request below.
Copy of email to workgroup participants of 25 July 2009.
Hi Alison and wiki friends -
BIG thanks Alison for your tireless work and contributions in shaping the outputs for our workgroup on workgroups.
I'm in agreement with all the proposed steps -- lets go for it. Another request -- we're proposing an important change to the current draft of the guidelines document. An important request.
Could participants of our workgroup to take a look and see whether you agree with our emergent thinking with regards to the shift from a "proposed" workgroup to an "official" WE workgroup for community-wide projects.
Early thinking suggested that the Charter for a Work group would need to be approved by the WE Community Council before being constituted as an "official" workgroup for community-wide projects, and therefore "legitimased" to start their work.
This seems impractical and doesn't really fit with the wiki way of doing things. However at the same, we need mechanims to promote transparency and enoucarage wide participation by the community.
Bar the exeptions of workgroups which would have financial, legal or technical implications for the WE community -- I don't see the need for Council approval of the workgroup before being consitituted as an official community workgroup. Council's role is one of governance to ensure transparent and participatory process. So my thinking is if the guidelines/policy contain the minimum standards for transparency and participation -- then work groups can self-organise and get their work done without unessary beuracracy.
To facilitate the process, I've suggested a few criteria which must be met before a workgroup can be deemed an official workgroup. When the policy proposal is finaly presented to Council for approval --- Council checks that due process has been followed -- if not the draft policy is deferred back to the workgroup . Please take a look and see what you think and your thoughts and comments on the relevant talk page.
Here is the guidelines proposal as it stands at the moment. (These guidelines will ultimately become a policy proposal for approval by Council for the functioning of workgroups). Take a look at the section on Initiating a Workgroup:
Workgroup:WikiEducator_Workgroups/Guidelines#Initiating_a_Workgroup
I've tabled a suggestion for the formal consitution of workgroups on the talk page here under the post "Determining the shift from proposed to official workgroup:
http://www.wikieducator.org/Talk:Workgroup:WikiEducator_Workgroups/Guidelines
Could you please comment on ore before 30 July whether you agree with the proposed criteria for an official workgroup suggest in disucssion post.
Cheers Wayne
My feeling is that guidelines should be part of the charter...what do others think about this?--Benjamin Stewart 17:34, 5 July 2009 (UTC)
Hi Ben,
Not sure I understand the question -- we have a chicken and egg scenario with this group being the first group to formalise and develop guidelines for the functioning of workgroups. The aim of this workgroup is to develop guidelines for consideration and approval by the COmmunity Council on the functioning of community-wide workgroups. Different workgroups will have different charters -- so I'm not sure how the proposed guidelines can be part of the charter for this group -- if you know what I mean?
- The draft guidelines suggest/require that future workgroups should draft a charter
- We should specify the minimum criteria for a charter in the guidelines
- We should provide an example charter template which could be used by future work groups.
Cheers
