The "Process Leaves" wiki is provided for WfMC work. It is easy to use once you learn, but you should expect to invest a little bit of time up front to learn to be effective, so that your work here will be effective.
Stop Using Email
Think twice before sending an email. Most of the mail sent would be better handled as a persistent page. More discussion of this can be found lower on this page.
Instead of email, you put the information on a page, and then send a link to the page. All wiki pages can be easily linked in an email message: just copy the address from the browser into the email message. This has the added advantage that if you need to change the message, you can do so, often before some people read it the first time. Later, when people come back to the subject, they will always have ready access to the most up to date information, instead of the information you had at the time you sent the original message.
Quick Start for Wiki Use
Planning Meetings / Events / Conference Calls
If you want to hold a meeting (including conference call), the first thing to do is to make a wiki page describing the goals of the meeting. As additional details become available put them on the page: date, time, duration, dial-in details, venue, subjects of discussion, agenda, groups that should be involved. Documents and presentations to be discussed at the meeting should be attached.
Do not wait until all this is known before you make the page for the meeting. At the first discussion of a potential meeting, a page should be made with whatever details are known at that time. As time goes on, more and more details will be included. If a detail is changed, then the old obsolete information is removed and replaced with the updated information.
Do not wait until it is decided to hold the meeting to make the page. Make a page for every proposed meeting. If the meeting is canceled, you will put that on the page as well, and anyone one who had been part of a discussion of a meeting will be informed that way that it is canceled.
In any discussion of the meeting by email should include a web link to the wiki page.
The single biggest conference call discussion item and email discussion item is for clarification of the current status of an event, and this can be eliminated through a properly maintained wiki page.
Running Meetings / Events / Conference Calls
It is a requirement that all WfMC meetings be held in a venue that offers internet connection to attendees so that they can access the wiki page for the current meeting, and for meetings that are being planned.
If you are running a meeting, then the agenda for the meeting should be placed on the wiki before the meeting starts. If the agenda calls for presentations, then the presentations should be attached (power point or PDF) before the meeting starts. All of this is so that attendees can come to the meeting prepared.
Attendees of the meeting should be made "members" of the wiki page so that all attendees can see and edit details on the page.
As the meeting starts, one or more attendees should be designated as notes/minutes taker. This is done in a "comment" on the wiki page. Each comment can be edited any number of times, but only by that one person. If there are multiple notes takers they will need to use different comments. If the meeting is a long one, the notes will probably naturally be broken into multiple comment objects.
As the meeting progresses it is natural that attendees will come up with unplanned presentations and documents. These should be attached to the wiki page, before presenting if possible (this is a good way to transfer the document to the machine attached to the projector) but in some cases attaching will have to be after. There is an "attachment reminder" feature that allows you as a meeting organizer to create an empty attachment, addressed to an email address, that will remind the attendee to upload the presentation later.
When the meeting is concluded, the meeting organization should revisit the wiki page one more time, clean up the various notes, attachments, and make a concluding summary of the meeting in a prominent place on the page. Then you are done!
Specifications
Much of the coalition work revolves around writing documents. Every document should have a corresponding wiki page for coordination of the document. Versions of the document can be attached if you choose. Comments on the documents can be made with the comment feature of the wiki. The wiki page should be maintained with the current status of a given document.
The wiki page should be created before a document is created; it should be created at the time that a document is proposed, and it should be maintained.
Public issues lists. A wiki is designed for a small level of discourse, but for major specifications, the amount of issue discussion and resolution would overwhelm the design center for a wiki. So public discussion can take place in two ways. (1) First is that issues on a particular document should be maintained in a public issues list. Google Code offers issue list capability that we are investigating. Each specification should state where the issues list for that spec is. (2) For more general discussion of the topic, particularly in ratified/released specifications, the WfMC provides forums for such discussion.
Initiatives / Working Groups
Every initiative (working group, discussion item) should have a wiki page associated with it in order to present the goals of the initiative and the current status. Email discussion of initiative issues should include a link to the initiative page.
An initiative is like a meeting, but it may encompass a series of meetings, and so justifies an overarching page which has links to the individual pages for the meetings. If an initiative or group has a recurring meeting, like a weekly conference call, it is possible to use that iniative page as the information about the recurring meeting, and just update it every week with the new information.
Organizing / Information Pages
While much of the wiki will be devoted to work of the WfMC, there are also pages which are informational in nature. The wiki is an easy way to make certain kinds of information available on the web. These will be produced by an initiative/working group. There is no particular WfMC guideline around this -- each group decides the information that it needs to make available. The only recommendation is that whoever authors the pages spend some time to make sure that the links to the pages and between pages are rich enough and clearly labeled so that your target audience can find their way around easily.
Discussion of "Email as a Problem"
The most important thing to learn is that email is often used inappropriately for coalition work. An email message has no lasting value. It is fine for messages that (1) have no lasting value and you want to throw away, and (2) you are certain of all the people who need that message.
The main purpose of the coalition is to communicate guiding information to the public. To make that communication consumable, we make specifications which are the results of discussions and agreements on particular technical topics. We put on events to educate people about the specifications and other guiding information. We have meetings to coordinate the development of this guiding information.
The principle challenge in all this is in engaging all of the relevant experts. We need to engage the experts in order to come to the right conclusion. We are not forcing a particular approach on the public, but instead are trying to find the best approach from the relevant experts. There are many topics and there are many experts. This is the first reason that email will not work: we can not possibly know all the experts who need to be involved in discussion of a particular topic.
principle one: when a document of any type is produced, it must be posted in a public place so that the relevant experts can find it.
The Process Leaves wiki is provided because it is an easy way to make a document available. Attaching a document to a wiki page is just like attaching a document to an email message, only the page remains available for review on the web. Wiki pages are indexed by google, and generally can be found by google searching. The Wiki has an internal search as well.
If you are thinking of emailing a document to someone, think again. You should ask yourself the question: "Am I 100% sure that the people I address the message to are the only people in the world interested in the document." If you made this document for the WfMC, then the answer is always NO because the coalition has many members who participate infrequently, and nobody knows everyone. If you are thinking of attaching a document to an email message, then attach that document instead to a wiki page, and send a link to the page.
principle two: If you have a question or an issue about a document, use an issue list or forum so that your question and answer become permanent record for others to use.
A big problem for any standards organization is recording the rationale behind a particular approach. The specific records the accepted consensus of the group, but almost never includes all of the abandoned or rejected ideas. The answers to such questions often explain the rational that a particular approach was taken.
principle three: If you are planning a meeting or event, then post the information about meeting in a public place where people can learn about it.
Don't send an email message to your friends about a possible meeting, unless you are 100% sure that you only want those people in the meeting, and you are 100% sure that the details of the meeting will not change between now and the meeting.
Posting a meeting proposal on a wiki provides a place where the final details of the meeting are held. Any changes to the meeting place will be incorporated right on that page. Email a link to the page. That link will always be good, regardless of how the meeting details are changed.
principle four: Don't wait until everything is known about a meeting/initiate to make the wiki page. Make the wiki page first, and then fill int he details collaboratively.
The wiki page is a way to communicate to potential participants and to come to consensus about the details of the proposal.
Is Everything Public Then?
The Process Leaves wiki provides two protection zones: public and member. Certain information on a "leaf" is available to the public (and google) and other information is for members only. Anyone can request to be a member, and any member can edit any information, either public or member.
If you know their email address, you can make a person a member of a page. It is that easy. Using their email address, they can identify themselves, log in, and access the page. Membership on that page does not give them membership of other pages -- so there is no danger -- they will have only public access to those other pages.
In general, all information should be public except in cases where you know that public exposure will cause confusion and/or misinformation. The member area can be used for discussion of controversial aspects of the document. It can be used for incomplete documents which might confuse people if they thought that it was a complete document.
But in general, you should probably err on the side of exposing more than less. Exposing things to the public rarely produces a flood of request, or even a flood of readers. Remember, documents can be updated at any time: If something is wrong in a document, the best way to find this is to expose to the public, let someone find it, and then correct the document quickly. Questions should be made in the public if possible, so that the answer is in the public as well, because it is likely that others have the same question.
Last edited by kswenson myopenid com 4/25/2009(Effective date 4/25/2009)
Running WfMC Business on a Wiki
The "Process Leaves" wiki is provided for WfMC work. It is easy to use once you learn, but you should expect to invest a little bit of time up front to learn to be effective, so that your work here will be effective.
Stop Using Email
Think twice before sending an email. Most of the mail sent would be better handled as a persistent page. More discussion of this can be found lower on this page.
Instead of email, you put the information on a page, and then send a link to the page. All wiki pages can be easily linked in an email message: just copy the address from the browser into the email message. This has the added advantage that if you need to change the message, you can do so, often before some people read it the first time. Later, when people come back to the subject, they will always have ready access to the most up to date information, instead of the information you had at the time you sent the original message.
Quick Start for Wiki Use
Planning Meetings / Events / Conference Calls
If you want to hold a meeting (including conference call), the first thing to do is to make a wiki page describing the goals of the meeting. As additional details become available put them on the page: date, time, duration, dial-in details, venue, subjects of discussion, agenda, groups that should be involved. Documents and presentations to be discussed at the meeting should be attached.
Do not wait until all this is known before you make the page for the meeting. At the first discussion of a potential meeting, a page should be made with whatever details are known at that time. As time goes on, more and more details will be included. If a detail is changed, then the old obsolete information is removed and replaced with the updated information.
Do not wait until it is decided to hold the meeting to make the page. Make a page for every proposed meeting. If the meeting is canceled, you will put that on the page as well, and anyone one who had been part of a discussion of a meeting will be informed that way that it is canceled.
In any discussion of the meeting by email should include a web link to the wiki page.
The single biggest conference call discussion item and email discussion item is for clarification of the current status of an event, and this can be eliminated through a properly maintained wiki page.
Running Meetings / Events / Conference Calls
It is a requirement that all WfMC meetings be held in a venue that offers internet connection to attendees so that they can access the wiki page for the current meeting, and for meetings that are being planned.
If you are running a meeting, then the agenda for the meeting should be placed on the wiki before the meeting starts. If the agenda calls for presentations, then the presentations should be attached (power point or PDF) before the meeting starts. All of this is so that attendees can come to the meeting prepared.
Attendees of the meeting should be made "members" of the wiki page so that all attendees can see and edit details on the page.
As the meeting starts, one or more attendees should be designated as notes/minutes taker. This is done in a "comment" on the wiki page. Each comment can be edited any number of times, but only by that one person. If there are multiple notes takers they will need to use different comments. If the meeting is a long one, the notes will probably naturally be broken into multiple comment objects.
As the meeting progresses it is natural that attendees will come up with unplanned presentations and documents. These should be attached to the wiki page, before presenting if possible (this is a good way to transfer the document to the machine attached to the projector) but in some cases attaching will have to be after. There is an "attachment reminder" feature that allows you as a meeting organizer to create an empty attachment, addressed to an email address, that will remind the attendee to upload the presentation later.
When the meeting is concluded, the meeting organization should revisit the wiki page one more time, clean up the various notes, attachments, and make a concluding summary of the meeting in a prominent place on the page. Then you are done!
Specifications
Much of the coalition work revolves around writing documents. Every document should have a corresponding wiki page for coordination of the document. Versions of the document can be attached if you choose. Comments on the documents can be made with the comment feature of the wiki. The wiki page should be maintained with the current status of a given document.
The wiki page should be created before a document is created; it should be created at the time that a document is proposed, and it should be maintained.
Public issues lists. A wiki is designed for a small level of discourse, but for major specifications, the amount of issue discussion and resolution would overwhelm the design center for a wiki. So public discussion can take place in two ways. (1) First is that issues on a particular document should be maintained in a public issues list. Google Code offers issue list capability that we are investigating. Each specification should state where the issues list for that spec is. (2) For more general discussion of the topic, particularly in ratified/released specifications, the WfMC provides forums for such discussion.
Initiatives / Working Groups
Every initiative (working group, discussion item) should have a wiki page associated with it in order to present the goals of the initiative and the current status. Email discussion of initiative issues should include a link to the initiative page.
An initiative is like a meeting, but it may encompass a series of meetings, and so justifies an overarching page which has links to the individual pages for the meetings. If an initiative or group has a recurring meeting, like a weekly conference call, it is possible to use that iniative page as the information about the recurring meeting, and just update it every week with the new information.
Organizing / Information Pages
While much of the wiki will be devoted to work of the WfMC, there are also pages which are informational in nature. The wiki is an easy way to make certain kinds of information available on the web. These will be produced by an initiative/working group. There is no particular WfMC guideline around this -- each group decides the information that it needs to make available. The only recommendation is that whoever authors the pages spend some time to make sure that the links to the pages and between pages are rich enough and clearly labeled so that your target audience can find their way around easily.
Discussion of "Email as a Problem"
The most important thing to learn is that email is often used inappropriately for coalition work. An email message has no lasting value. It is fine for messages that (1) have no lasting value and you want to throw away, and (2) you are certain of all the people who need that message.
The main purpose of the coalition is to communicate guiding information to the public. To make that communication consumable, we make specifications which are the results of discussions and agreements on particular technical topics. We put on events to educate people about the specifications and other guiding information. We have meetings to coordinate the development of this guiding information.
The principle challenge in all this is in engaging all of the relevant experts. We need to engage the experts in order to come to the right conclusion. We are not forcing a particular approach on the public, but instead are trying to find the best approach from the relevant experts. There are many topics and there are many experts. This is the first reason that email will not work: we can not possibly know all the experts who need to be involved in discussion of a particular topic.
The Process Leaves wiki is provided because it is an easy way to make a document available. Attaching a document to a wiki page is just like attaching a document to an email message, only the page remains available for review on the web. Wiki pages are indexed by google, and generally can be found by google searching. The Wiki has an internal search as well.
If you are thinking of emailing a document to someone, think again. You should ask yourself the question: "Am I 100% sure that the people I address the message to are the only people in the world interested in the document." If you made this document for the WfMC, then the answer is always NO because the coalition has many members who participate infrequently, and nobody knows everyone. If you are thinking of attaching a document to an email message, then attach that document instead to a wiki page, and send a link to the page.
A big problem for any standards organization is recording the rationale behind a particular approach. The specific records the accepted consensus of the group, but almost never includes all of the abandoned or rejected ideas. The answers to such questions often explain the rational that a particular approach was taken.
Don't send an email message to your friends about a possible meeting, unless you are 100% sure that you only want those people in the meeting, and you are 100% sure that the details of the meeting will not change between now and the meeting.
Posting a meeting proposal on a wiki provides a place where the final details of the meeting are held. Any changes to the meeting place will be incorporated right on that page. Email a link to the page. That link will always be good, regardless of how the meeting details are changed.
The wiki page is a way to communicate to potential participants and to come to consensus about the details of the proposal.
Is Everything Public Then?
The Process Leaves wiki provides two protection zones: public and member. Certain information on a "leaf" is available to the public (and google) and other information is for members only. Anyone can request to be a member, and any member can edit any information, either public or member.
If you know their email address, you can make a person a member of a page. It is that easy. Using their email address, they can identify themselves, log in, and access the page. Membership on that page does not give them membership of other pages -- so there is no danger -- they will have only public access to those other pages.
In general, all information should be public except in cases where you know that public exposure will cause confusion and/or misinformation. The member area can be used for discussion of controversial aspects of the document. It can be used for incomplete documents which might confuse people if they thought that it was a complete document.
But in general, you should probably err on the side of exposing more than less. Exposing things to the public rarely produces a flood of request, or even a flood of readers. Remember, documents can be updated at any time: If something is wrong in a document, the best way to find this is to expose to the public, let someone find it, and then correct the document quickly. Questions should be made in the public if possible, so that the answer is in the public as well, because it is likely that others have the same question.