Name: Vrushti Mody
MediaWiki user: VrushtiMody
Time Zone: UTC+5:30
Typical working hours: 17:00 - 1:00
I was introduced to open source software recently and felt like it is the best way to learn, explore and contribute to the community. On digging deeper, I learnt about several open Source initiatives, Google Season of Docs being one of them.
Upon reviewing the organisations, the project ‘Audience research and user experience’ targeting understanding the wants and needs of the fellow community struck a chord with me. The Wikimedia community has been really supportive ever since I joined the chat and sent my first email.
I want to set foot to this amazing open source culture and hopefully learn and grow as a technical writer during the process.
While we know that good technical documentation is essential to our community of volunteer developers, there is still a lot that we do not know about our audiences and their needs.
This project is meant to help us gain a better understanding of who is using technical documentation on MediaWiki and Wikitech, how they are responding to the current documentation, and what their wants and needs are for better technical documentation. The results of this project will help us build a technical content strategy that works for our users and delivers real value to them.
- Understanding loopholes in existing documentation
- Fixing the target audience and sample population
- Working on participant demographics
- Categorise the problems with existing documentation
- Design the basic structure for the survey keeping in mind validity, reliability, replicability and generalizability.
- Create targeted questions for the survey
- Study questionnaires available
- Brainstorm on how to Incentivise the survey for greater reach
- Use of wikitech-I for the survey
- Analysis for hosting the survey (Google form, Survey monkey, hosted site, etc)
- Incorporate existing feedback into the analysis (eg, Did you find it helpful button)
- Carry out primary analytics to obtain results
- Use advanced statistics to obtain secondary results
Work on pop-ups such as rating the documentation on clicking the back or close button
Sarah R. Rodlund
Zulip will be the primary mode of communication with my mentors. Wikimedia’s IRC channels and Email will be used for discussions with the community.
Discussions about specific tasks will happen in the comments section of the Phabricator tasks.
This project is broadly divided into two phases:
- Creating a survey for understanding the user preferences
- Obtaining insights from the survey
**//1. Creating a survey for understanding the user preferences//**
//Why is it needed?//
> Technical Documentation survey is integral in obtaining customer feedback about the technical documents of a project. Not only does it provide an in-depth understanding of the product usage, but also helps point out things that might not be evident initially. As it happens, when making a product, we get so involved in it, we are not able to look at it from different perspectives. This is where a technical documentation survey makes the job easier. Insights from customers are essential to determine areas where improvement is needed.
The survey I will make will help achieve the following goals. I will also describe the methodology to be used to achieve that goal and why it is needed.
1. Identify objectives
I will start with my hypothesis with a clear idea in my mind of the information that is required. This will establish various parameters of the survey like: the purpose, the rating scale to be used and what can make the data actionable.
2. Determining Sample Target
The two main factors to consider here are:
What is the target population?
What is the minimum number of responses needed from said population to establish the survey as reliable enough.
3. Making the questionnaire
- The survey will begin with a title and a short abstract outlining the purpose of the survey in a manner that is easily understandable and not using jargon or explaining the complexities of the survey. It will also inform the participant of the confidentiality of the survey and its overall length with average time taken to complete it.
- Questions will be framed in simple, direct and unambiguous language. Each question will be measuring at least one thing, in an unbiased manner.
- The questions will be concise and clear. Extra instructions will be added where necessary. Care will be taken to keep the level of language low, without being condescending while still achieving our goals.
- Response categories will be kept clear, discrete and will avoid usage of words that do not clearly define the parameter. For example, a range will be used instead of responses like “often” and “sometimes”.
- General instructions will be provided to respondents at the start of a new section along with specific instructions to aid in the completion of a particular question.
- Only one question will be asked at a time, that is, two parameters will not be merged into one question which can create confusion for the respondents as to which parameter is to be kept in mind while responding.
- Biased questions will be avoided. Questions like “What did you like about this feature” will be avoided as they inherently assume that the respondents liked the said feature in the first place. Such questions will be framed as a yes/no question which will then proceed to ask why or why did not the respondent like said feature.
- It is important to understand that all questions will not be relevant to all respondents. Hence, filter questions will be used to allow respondents to bypass questions not relevant to them.
**//2. Obtaining insights from the survey//**
- //Understanding Participant Demographics//
Understanding and categorising the sample population based on demographics will help understand which category of people need what kind of help w.r.t the documentation
- //Preliminary Analysis//
> “Preliminary analyses on any data set include checking the reliability of measures, evaluating the effectiveness of any manipulations, examining the distributions of individual variables, and identifying outliers.”
This would be helpful to briefly understand the problems to work towards existing solutions.
- //Secondary Analysis//
The secondary analysis will help get a broader perspective w.r.t results of the survey. Two of the many tests that would be used are Hypothesis analysis and correlation analysis
> “Hypothesis testing in statistics is a way to test the results of a survey or experiment to see if they have meaningful results. It is basically testing whether the results are valid by figuring out the odds that your results have happened by chance. If your results may have happened by chance, the experiment won’t be repeatable and so has little use.”
In the real world, it’s tough to get complete information about the population. Hence, we draw a sample out of that population, the results of the survey in this case and derive the same statistical measures. Thus it is important to find out if there is enough statistical evidence in favour of a certain belief, or hypothesis, about a parameter. Hypothesis analysis will be used to determine if the results of a survey are statistically significant to confidently say that those results are indicative of the user experience of the product in general.
> “Correlation Analysis is a statistical method that is used to discover if there is a relationship between two variables/datasets, and how strong that relationship may be.”
It will be used to analyse quantitative data gathered from the survey, to identify whether there are any significant connections, patterns, or trends between the variables.
Community bonding period (7th - 25th August)
Week 1 (26th August - 1st September)
Week 2 (2nd - 8th September)
Week 3 (9th - 15th September)
Week 4 (16th - 22nd September)
Week 5 (30th September - 6th October)
Week 6 (7th - 13th October)
Week 7 (14th- 20th October)
Week 8 (21st - 27th October)
Week 9 (28th October - 3rd November)
Week 10 (4th - 10th November)
Week 11 (11th - 17th November)
Week 12 (18th - 24th November)
Week 13 (25th - 29th November)