Transparency/Practices

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Correct.svg This page is currently a draft. More information pertaining to this may be available on the talk page.

Translation admins: Normally, drafts should not be marked for translation.

Background[edit]

This page is an attempt to start documenting and sharing some good practices among the Wikimedia community (and perhaps beyond!). It started because WMF staff were discussing transparency and felt the need for a good list of practical guidelines and examples.

Feel free to add to this page!

Benefits of Transparency[edit]

  • It saves you time.
    • It means you can reuse the information so you don't have to rewrite it multiple times.
    • Other people can come and make it better.
    • It reduces communications friction, especially if you're publishing in a well-understood channel, because people trust that they can find the information and are less likely to bother you about it and reduces suspicions that you are hiding information from them.
    • Transparency builds trust. High-trust communities require less structure, which means greater agility, efficiency, and speed. Trust makes everything easier!
    • showcase reform
    • educate stakeholders [1]

Good Practices[edit]

  • Public is the default; have a reason to keep things private.
    • Draft your thinking in public whenever possible. You can always mark it as early thinking to help take the pressure off - the "Under Construction" template ({{draft}}) is your friend :) Don't wait for everything to be perfect before you share it on-wiki or in other public venues.
    • Premise: Renaming pages is cheap and easy. Don't let Naming paralyze you.
    • Working in public is an investment. It may require more time upfront, but it saves times further down the line by avoiding frustration and surprise.
    • Example: WIkimedia Strategy (2009-2010). See also former Wikimedia Foundation ED Sue Gardner's blog post about the importance of transparency by default in that and other processes.
    • When you need to redact information, redact the minimum information that you need to.
  • With newly formed groups, have an explicit conversation about the value of transparency. Get specific about what it means and how it might translate into practice.
    • If there is resistance or discomfort, listen carefully to the objections. Try to figure out higher-level values around which there might be alignment, and find agreements that address those values.
    • It's a good idea to do this exercise regularly even with groups that already agree on and practice transparency as a value.
  • Engage in direct conversations with community members in the communities your work affects as early as possible
  • Don't worry about overwhelming people with information - if they're interested they will engage, if they aren't, they simply won't.
  • It's ok to make mistakes; people will usually forgive you. So you've made a mistake and it's public...
  • Take advantage of events and other venues to share updates, promote a specific discussion and improve communication
  • Working on a public wiki makes you part of the community. That's a good thing.
  • Examples of things that may not be shared include...
    • Personal data. Just because a volunteer has given the address you can send a T shirt or reference book to, that doesn't mean you have their permission to publicise where they live. or what Tshirt size they are.
    • Dietary information. Event catering, even for an editathon can be complex. People's willingness to publicly tick Vegetarian, kosher, halal, etc varies. If you know your regulars then consider an option such as avoiding pork and or including a larger proportion of vegetarian food than you expect vegetarians.
    • Disability information about individuals. Indicating if an event has step free access or giving an email address for people to ask such questions is better than requiring it to be publicly queried on wiki.
    • Pregnancy. You may know that a colleague is pregnant and "due" at the time of a particular conference, but she may not want to disclose that publicly until much closer to the event.
    • Negotiating positions. Whether you are buying a bunch of servers or hiring a conference venue you don't want the person you are negotiating with to know the maximum you can afford to pay or what their rival has just bid for the work.
  • Find good examples from other NGO and open source organizations to follow

Teams[edit]

  • Have a clear public channel to share updates with interested communities (most likely Meta or MediaWiki.org) - crosslinking to other projects is OK!
    • Set clear expectations for your team about where/when/how you will communicate
    • If a conference appearance from team members is expected, disclose this on your team page so that others can come find you and talk to you.
  • Be clear about people's roles in a team and who to go to for what. A good way to do this is to have a "Team page" with names, roles, photos, if desired), and areas of expertise or responsibility.

Experiences/Practical Examples[edit]

Add links, examples, or short stories here!

  • Re: Drafting on Meta
  • Re: Working with Translators
  • Re: Soliciting Community Feedback
    • Community Consultations that have worked well:
    • Soliciting individual feedback in ways that has worked well:
  • Examples of times when consultation / discussion / feedback resulted in new ideas (or modified ideas) that were better than the one we originally had in mind. Look into Nemo's contributions to find plenty of that? :)

Resources[edit]