SandBox
|
Size: 10098
Comment:
|
Size: 3592
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #title Building And Maintaining Transparency | #title Regular Workflow Assessment |
| Line 5: | Line 5: |
| Transparency is not only a key theme throughout this book, but throughout community building in general. Openness is an important ingredient in healthy communities, and your community needs to feel that there is transparency throughout its governance, processes, communication, and workflow. |
''From The Art Of Community by O'Reilly (http://www.artofcommunityonline.org) by Jono Bacon'' |
| Line 10: | Line 8: |
| In terms of workflow, transparency can be divided roughly into three areas: | Like any process, structure, governance, or other agreed method of working, workflow should always be subject to change. Your workflow and the tools that are crystallized in it should always reflect the optimal way in which your community can work. If the tools become too complex and too laborious, you should consider adjusting your workflow, and possibly your tools as well. |
| Line 12: | Line 14: |
| * Tool access | One of the most useful lessons that I have learned in my community work is that you should regularly reassess everything: your workflow, processes, governance, and anything else. A community is built on a set of rapidly changing people, needs, and requirements. Regular reassessment is important to ensure that your workflow is matching the day-to-day work of your community. |
| Line 14: | Line 20: |
| * How open and accessible are the tools that form the foundation of your community and workflow? | I recommend that you set this regularity now. The length of time before reassessments is really up to you and your needs, although I would make sure to do a reassessment at least once a year. |
| Line 16: | Line 23: |
| * Communication | == Gathering Structured Feedback == |
| Line 18: | Line 25: |
| * How open and accessible are the communications channels in your community? | When performing your reassessment, your aim is to find solid feedback about the good and bad aspects of your current workflow. The real value that you should be seeking is constructive, objective feedback from those who really dig into the workflow. Those community members who are using the workflow day in and day out will have the most valuable feedback for you. |
| Line 20: | Line 30: |
| * Reporting | Before you consider changing any aspects of your workflow, you should gather an extensive level of feedback and use it to identify correlations in aspects that work and don’t work. A useful technique for getting good feedback is to produce an online survey. There are a number of free survey sites that enable you to produce a set of questions and have anyone fill in the survey. Many surveys also allow you to choose between invitation-only responders and a free-for-all public survey. This is an important decision when running the survey. There are benefits and disadvantages to both. For open public surveys, there is always a risk of getting a lot of inexperienced feedback that is not particularly useful, and this noise can skew the results. |
| Line 22: | Line 39: |
| * How well do you report what your community is doing? | On the other hand, public surveys feel more community-spirited: they are open and accessible, and anyone can participate. Invitation-only surveys allow you to choose who responds, and if you choose wisely (read: not just people who will give you good feedback), you can get some great objective and practical results. On the flip side, invitation-only surveys feel closed, cliquey, and restrictive. |
| Line 24: | Line 45: |
| Each of these three areas is important for a healthy community. Let’s now spend some time looking into each of them, and cover some of the key points in keeping your community open and accessible. |
I recommend you do both. Start out with an invitation-only survey with at least 10 respondents. When you have this feedback gathered, open the survey up to anyone. Keep the public survey open for a set period of time (a month is a good figure), and promote the survey in places where your community reads and resides. You can then use both sets of results to draw conclusions. I would recommend that you put more faith in the invitation-only survey results, as they come from your key community members, but the public survey will undoubtedly uncover some useful results. |
| Line 28: | Line 53: |
| ---- || ||<:99%>'''TRANSPARENCY FOR NEW CONTRIBUTORS'''|| || An important area in terms of transparency is how people who are not yet trusted contributors can contribute to the project to gain trust. ---- == Tool Access == You should always ensure that the tools that you choose to use for your community are easy to access, well documented, and freely available. When you have decided on your toolchain, you should ensure it is well documented on your community’s website. You should specify: * The tools that are used in your project. * Where you can obtain the tools required. * Instructions for how to use these tools to obtain the work that your community produces (such as the source code for an application) and how to run it. Another useful goal to aim for, particularly with regard to software development, is to ensure that each contribution is documented. Ideally, you want any contributor to be able to point to any of her contributions by referencing a URL on the Internet. If every contribution can be referenced, your community will be transparent by definition. == Communications == Openness in communication is essential. Your communication channels are the very lifeblood of how ideas, problems, and solutions flow between the different members of your community. The golden rule here is to ensure that anyone (including those who are not currently part of your community) can reference every communication online after it has occurred. I would like to be able to go to any community and read conversations that I was not a part of so I can evaluate the decisions that were made. This is happening today in most open source projects. Most projects have open mailing lists, and these lists have publicly visible archives that are automatically made available on the Web. Many communities also have small programs called “bots” that log IRC conversations and make the discussions available on the Web. I would highly recommend making these kinds of archives and logs available. In many cases, it is as simple as switching on a configuration option. The only time I consider it reasonable to have private archives is when a communication channel is being run by a Community Council. For many communities, sensitive and private discussions, particularly those around conflict, are taken to the council. There are also conversations that pertain to an individual, such as if a contributor has had some complaints made about him. These kinds of discussions need honest input from the council members, and if archives of the conversation are available, many council members will feel uncomfortable making statements that they would otherwise make in private. Just compare and contrast the statements you yourself make in public and in private. Transparency in communications is not purely about the free availability of archives, though. It is also about ensuring that everyone in your community is welcome to participate and communicate in an open manner. There is one enemy to this kind of participation—cliques. Cliques exist everywhere. Some of them are pronounced, such as the thousands of invitationonly clubs and associations across the world. Some of them are less pronounced, such as the informal, unwritten, yet obvious groupings that occur when we are all at school. There is nothing wrong with groups; they are natural functions of human social interaction. But they can be destructive in communities that are explicit about their openness to new contributors. I noticed this for the first time years ago when I set up my Linux User Group in Wolverhampton. As the group grew and regular members attended, a sense of familiarity set in. There were insider jokes, everyone knew the regulars, and the group was generally bonding. Although we welcomed new members, we occasionally heard of people being put off due to “cliquishness.” Although you should not have overt cliques in your community, you also should not inhibit the ability for people to bond and form personal relationships. As you continue to engage with your community, there are some members who will naturally group together due to similar perspectives, sense of humor, or other attributions. Encourage and welcome these groups, but always be cognizant of the risk that these groups will be offputting to new users. Everyone knows what it feels like to feel unwelcome, but not everyone knows what it feels like to be a possible cause of that feeling. == Reporting == The final aspect of transparency with regard to workflow is keeping everyone on the same page. This is all about reporting. Some time ago, we wanted to improve how different parts of the Ubuntu community communicate what they are working on. We have hundreds of contributors all over the world, each working on different teams, and I was keen to see a single web page from each team with bullet points containing what they had achieved that month. This was something of a challenge. Reporting is not a natural by-product of community, and most communities struggle at producing metadata such as this. Communities are great at doing the work that interests them, but activity reports and additional information does not flow naturally. The only chance of making this work was to make the process as simple as possible, and to encourage as many people to engage in the process as possible. The process I developed was about as simple as I could get. I had a set template on the Ubuntu wiki, and each template was named for the given month. I asked all teams to get their feedback in by the 20th of every month. This would leave a few days to tidy up any missing pieces of the report and announce it on the 22nd of each month. For each team, I asked someone to be a team reports contact, and every month I would nag them to get their content in. Some teams would be as reliable as you could imagine. Some less so. In general, though, the team-reporting framework generated some useful content. The value of the team reports was obvious. They were well received, and it was fascinating and inspiring to see what everyone was working on. The approach I fleshed out could easily be rolled out to your own community. You should seriously consider it. Another little story I will share about reporting was one that we faced at our Ubuntu Developer Summits (UDS). At every UDS we would have a large number of discussion sessions, and we had some facilities in which people could listen in to the sessions through an audio stream and communicate with us via IRC. Despite these methods of engagement, we still wanted to release a set of proceedings from the summit. This would be a summary of decisions made at UDS that would affect the development of the next version of Ubuntu. Our first shot at this was to produce a wiki page for each track at UDS and ask attendees to update the page at the end of each session. A simple process, but it got limited uptake. There simply was not time at the end of sessions for people to summarize the agreements. As such, we got relatively sparse proceedings for each track. For the next UDS, we had a different idea. In recent years microblogging platforms such as Twitter (http://www.twitter.com) and identi.ca (http://identi.ca) have become a common part of many people’s workflow. It is not uncommon to send out a quick “tweet” or “dent” to let the world know what you are doing. We figured this could be an interesting approach for our proceedings at UDS. To do this, we conducted an interesting experiment that worked rather well. Using identi.ca we registered an account for each track at UDS. In each track room we had the login details for the account on the whiteboard. We would then encourage everyone to microblog as the sessions continued. The final part of the process was to write a script that took each of the microblog entries and divided the messages into the relevant sessions. As an example, all the messages on the community track between 1 p.m. and 2 p.m. would be automatically grouped under the heading “Making LoCo Teams Rock,” the name of the session at that time on the community track. The moral of this story is that to get effective reports, the method needs to be as low-friction as possible. People were already used to microblogging, so asking people to microblog sessions was entirely natural for many people. This is the essence of effective reporting. ---- || ||<:99%>'''COLLABORATIVE TEXT EDITING''' || || Another useful tool that has been a common staple at UDSs is a collaborative and cross-platform text editor called Gobby (http://gobby.0x539.de/trac/ ). In the Gobby text editor, multiple people can edit the same document at the same time. You see the changes that other people make in real time in your instance of Gobby. It is a clever little tool. Gobby is useful when multiple people are working together to record notes for a session or working together on a specification or strategic document. ---- |
When you have performed your surveys, you should schedule some meetings with your community to discuss the results, propose solutions, and share more experiences. As with normal meetings, these meetings should be very focused on driving to a conclusion: finding solutions to the problems. |
From The Art Of Community by O'Reilly (http://www.artofcommunityonline.org) by Jono Bacon
Like any process, structure, governance, or other agreed method of working, workflow should always be subject to change. Your workflow and the tools that are crystallized in it should always reflect the optimal way in which your community can work. If the tools become too complex and too laborious, you should consider adjusting your workflow, and possibly your tools as well.
One of the most useful lessons that I have learned in my community work is that you should regularly reassess everything: your workflow, processes, governance, and anything else. A community is built on a set of rapidly changing people, needs, and requirements. Regular reassessment is important to ensure that your workflow is matching the day-to-day work of your community.
I recommend that you set this regularity now. The length of time before reassessments is really up to you and your needs, although I would make sure to do a reassessment at least once a year.
Gathering Structured Feedback
When performing your reassessment, your aim is to find solid feedback about the good and bad aspects of your current workflow. The real value that you should be seeking is constructive, objective feedback from those who really dig into the workflow. Those community members who are using the workflow day in and day out will have the most valuable feedback for you.
Before you consider changing any aspects of your workflow, you should gather an extensive level of feedback and use it to identify correlations in aspects that work and don’t work. A useful technique for getting good feedback is to produce an online survey. There are a number of free survey sites that enable you to produce a set of questions and have anyone fill in the survey. Many surveys also allow you to choose between invitation-only responders and a free-for-all public survey. This is an important decision when running the survey. There are benefits and disadvantages to both. For open public surveys, there is always a risk of getting a lot of inexperienced feedback that is not particularly useful, and this noise can skew the results.
On the other hand, public surveys feel more community-spirited: they are open and accessible, and anyone can participate. Invitation-only surveys allow you to choose who responds, and if you choose wisely (read: not just people who will give you good feedback), you can get some great objective and practical results. On the flip side, invitation-only surveys feel closed, cliquey, and restrictive.
I recommend you do both. Start out with an invitation-only survey with at least 10 respondents. When you have this feedback gathered, open the survey up to anyone. Keep the public survey open for a set period of time (a month is a good figure), and promote the survey in places where your community reads and resides. You can then use both sets of results to draw conclusions. I would recommend that you put more faith in the invitation-only survey results, as they come from your key community members, but the public survey will undoubtedly uncover some useful results.
When you have performed your surveys, you should schedule some meetings with your community to discuss the results, propose solutions, and share more experiences. As with normal meetings, these meetings should be very focused on driving to a conclusion: finding solutions to the problems.
itnet7/SandBox (last edited 2017-09-19 03:15:55 by itnet7)