Kendra Modus Operandi
The following applies to KendraInitiative c/o KendraFoundation:
- All discussion that takes place within the realms of KendraInitiative (via any websites under kendra.org.uk or via any hosted email discussion lists) will be openly archived for public consumption. This includes all discussion on project development and financial issues.
- Operating for and on behalf of all participants equally. Providing equal opportunity to access decision making processes for all.
- Inclusive and non-confrontational
- It is in our interests to get along with everyone. So, we will seek to work with everyone that has an interest in what we are doing. There will never be any name calling. Only positive vibes allowed.
- Positivity and solution creation
- Be positive in our language with the aim of creating solutions. Be open to other peoples' ideas and encourage.
- There is no restriction to participating in KendraInitiative. Anyone can come and play. But if you want to post your comments within the realms of Kendra then you have to sign what you say with your real name. Anonymous listening is always allowed within the realms of Kendra.
- This only applies to KendraFoundation and not to any other companies that are participating in KendraInitiative. Of course we want people to make money from providing products and services. I know it's obvious but I wanted to clarify anyway.
- The project grows at its own speed - depending on the state of the industry and the amount of participants and the amount of effort put in. I've just put this in for people getting frustrated that the project isn't going fast enough. The project goes as fast as the people involved enable it to go.
- A useful word encapsulating a process of continuous revision is [Kaizen]. So, we go through a process of iteration - small steps. Continually improving on our models/trials/demonstrations based on feedback from participants.
- Being open and transparent isn't enough. In order to capitalise on the advantages of open peer review we need to present our ideas and thought processes in clear and structured ways. So that newcomers to the project can easily see what the current state is and track the reasons and thoughts behind why we are here. So, that means all ideas should be presented as documents or part of documents in a public space like this wiki.
- Using email lists *tends* towards a fractured set of ideas whereas using documents *tends* towards unified ideas. And in order to make a decision based on consensus we need unified ideas.
- Self documenting discussion.
- Add ideas but don't remove ideas. Popular ideas will rise and unpopular ideas will fall. But there is no reason not to be inclusive of all ideas. And there is every reason to be inclusive of all ideas.
- Include all for the avoidance of doubt. There is no such thing as common sense. Everything must be explained. There is no such thing as 'obvious'.
- Need to be able to invite outsiders to comment on and question our thoughts. So, we need to present our thoughts in a clear and structured way.
- Need to de-couple requirements from solutions.
- Be low cost - inexpensive to develop, implement and maintain.
- Use existing, proven technologies (this will keep costs low, and increase confidence in solutions).
- Be as simple as possible.
- Meeting participants should make proposals and ask for a vote/consensus by "all those in favour say eye". If there are people not in favour then discussion continues until unanimous or the proposer gives up.
- At the start of each meeting we agree the duration of the meeting and also what topics will be covered.
- At the end of each meeting we decide when and where the next meeting will be held and also recap the decisions that have been made.
- All discussion should be based on publicly available documents - mostly wiki pages. Wiki pages can be edited live and voted on while the meeting is in progress.
- During the meeting/call one person can be editing the page with constant saves and refreshes but other participant can IM their ideas for text so that the editor can just cut and paste to the page update. That way everyone gets to type their bits.
- Document headers a la [W3C] are used.
- Documentation is in the third person.
- Documents interrelate and reference each other and do not stand in isolation.
- Name of people are their proper WikiName and never their first names alone.
- Documents are built and read as an article rather than a threaded discussion.
- Documents can initially have signed comments with the view of taking these signatures out of the document after a review discussion between interested parties. --DanielHarris
- All documents should be living documents and reflect the current state of thinking rather than a historical record. The history of thinking can be found in the revisions if needed. This means that action plan pages with current states of play are preferable to pages and pages of meeting minutes that are hard to sift through. So, pages should be continually refactored and kept in step with current thinking.
- Link as many terms as possible to existing internal wiki pages - like KendraInitiative.
- Use bullet points (single or multiple stars: *) and bolded (three single quotation marks: ''').
- Use standard font size - don't use large font sizes.
- Use English and keep it simple and concise. This is an international effort and so many people do not have English as their first language.
- Avoid abbreviations and always explain them if they must used.
- Don't use TABs to format.
- Avoid shortening Kendra to 'K' or 'Ken' or 'Kend'.
- Continual refining, reviewing, refactoring and refreshing and avoiding document bloat.
- Don't place "rough notes" into the wiki. Someone will need to clean them up.
- Need receipts for all expenses.
- At all times there is a requirement to have fun!
![[Home]](/graphics/kendra-small.gif)