WikiEducator:Guidlines for technology feature requests

Objectives

The purpose of this page is to facilitate community discussion and recommendations on: The values and principles which should guide our technology decisions The processes WikiEducator should implement regarding technology choices and decisions Workable solutions that ensure that community requests can be implemented at a technological level ensuring that the relevant technology will scale and not compromise the security of the WikiEducator site Workable solutions that ensure that WikiEducator can afford to implement technology requests The development of a draft policy for approval by the WikiEducator Community Council

Values and principles

WikiEducator is a community-driven, open education initiative. Our technology decisions:

1. Support the WikiEducator community values of:
   • ensuring social inclusion through responsible technology choices;
   • promoting the essential freedoms of all educators to teach with the technologies and contents of their choice;
   • responding to the unique requirements of teaching and learning; and
   • encouraging a forward looking disposition for relevant, appropriate and sustainable innovation.
2. Require the use of software licenses approved by the Free Software Foundation or the Open Source Initiative.
3. Observe the requirements of the free cultural works definition.

Process for community technology requests

1. Raise and support discussion about the issue or technology request on the Wikieducator forum
2. Refine the issue or request into definite points of detail and suggestion
3. Post the refined issue or request to the Wikieducator Feature Request Page
4. Collect feedback from experienced technicians and the Council and refine the issue or request further so that it is a clear and achievable request for action.
5. When the request for action reaches maturity through discussion and agreement, obtain at least 10 petition signatures from Wikieducator Users and submit it to Council for implementation voting
6. Council will vote on the request and document discussion and voting results. If the request is rejected Council must explain why on the request page and make suggestions for improving the request.
7. The request is further developed taking into account the recommendations from Council and at least 10 petition signatures must be obtained again so as to indicate support for the new version
8. The new version is submitted to Council again to begin at step 6 again.

Discussion thoughts - --Wayne Mackintosh 03:35, 5 December 2008 (UTC)

Leigh, this is great start -- thanks :-). A few initial thoughts and feedback. After sleeping on this, I'll have a stab at working on a straw dog derivative of the points you've put down as a starting point:

1. Given the importance of keeping a history on technology decisions -- after the suggestion is raised in the forums, wouldn't it be better to require all discussions points etc to be in the wiki?
2. I'm wondering whether we need a requirement of 10 signatures to action the process for a decision. Perhaps all we need is a confirmation from 3 of the top 50 editors to establish a working group to research a proposal -- conceivably these are folk who know the community well. The important components here are the discussions and research -- not the action to suggest a new feature or extension.
3. Fabian Tompsett has made an excellent suggestion of using community work groups (see here. I think that this is an excellent approach to use with technology related (and other proposals). Should we specify a minimum work group size? If so, would 3 be a reasonable number?
4. I not sure that Council is the best structure to take community decisions relating to technology because:
   • Technology decisions are operational -- not a governance matter. Very often the root of poor governance is getting involved with micro-management;
   • From a practical point of view, Council would typically meet twice a year which could delay the implementation of important technology decisions;
   • Based on contemporary management thinking which advocates breaking down hierarchical levels --- I'm not sure that instituting additional hierarchies for operational decisions is in the best interests of our project.
   • The governance role of Council is to approve a robust and sensible policy -- in this regard I think that we should develop a solid policy for consideration by Council which would give the Community the scope room and authority to take operational decisions. I think it would be advisable to incorporate an appeal mechanism in the draft policy where the community feels that process wasn't followed.
5. When dealing with technology -- there is always a difficult balance between individual needs and what is technically doable --- in this regard I would suggest a veto vote by the WikiEd Tech team. The veto should be restricted to proposals that would compromise the security of the site, or result in maintenance issues where the technical team do not have the human resource or financial capacity to implement and maintain the technology. I think we should also provide an appeal mechanism for Council to consider cases where folk feel that the veto was unduly applied
6. In wiki communities -- its always difficult to specify threshold numbers. As the community grows -- do we increase the threshold of 10? What if we don't meet the threshold in the prescribed time? I'm wondering whether we shouldn't have an open vote for a predetermined time once the working group research is completed. This should designed to be a general indicator of support for the proposed feature. Assuming there is a majority vote, and that the technical team confirm that there are no issues -- this should effectively constitute the go / no-go decision.
7. It would be prudent to have the Exec Committee of Council to check that the policy was implemented properly and then to give the go-ahead for implementation

A few reflections inspired by your first draft.

How do we ensure that requests are implementable?

• Add your suggestions regarding technical considerations, priorities, affordability etc.

• they don't compromise the performance of existing technical functionality in a negative way (i.e., existing stuff doesn't work)