While we don't expect the following will be published, here are our notes on the outline for the session:
Hi all,Sorry it took us so long to send this. :(
Following is the blurb for the session Reef and I will be running on non-code contributions, a.k.a. community assisted triage.
A discussion of how the NVDA community can make non-code contributions.
As a popular screen reader with wide ranging support of 3rd party applications, naturally new github issues are raised frequently. These maybe requests to support new applications, features of existing application, bug reports, and other kinds of requests. NV Access tries to triage these issues as they are raised, in order to prioritise and define the requirements for development. NVaccess is a small team with limited resources, and it is difficult (or impossible) to keep up with this task. This talk aims to help the community to understand what our aims are during triage, and to guide the community on how they can contribute to this process. Since much of this process only requires a user level understanding of NVDA, this work can be done by non-programmers.
- This will include a discussion of "why do we prioritise?" and what does it mean for an issue to be "well defined".
- Discussion / explanation of user stories.
- Discussion of the common "types" of issues.
- Discussion of exactly how the community can help.
- As new issues are raised on github, we try to triage them. Firstly we want to catch high priority issues and ensure that they are attended to first. Secondly, we want to ensure that there is enough information on the issue so that it can be well understood and work can start on it when it comes to the front of the queue
- As it stands we have more issues coming in than we have the ability to process.
- Many issues require more information to be gathered in order to quickly and confidently apply a priority.
- This makes it hard to prioritise, and find the requests that will provide the biggest impact.
- It's common that those raising the issues don't know what information to provide, or don't know how to get it.
- The community can be of great help in this process, both in providing the right information for issues but also in working with other, less experienced users to gather the right information.
- This session will discuss how to get the best possible benefit from user feedback by considering the kind information we need in order to progress to prioritisation and development on an issue.
- Some analysis of the issue and summarising the key points can help to speed up applying a priority to the issue.
- Try to avoid talking about specific solutions, first we must understand the problem. This will help to increase the likelihood of a more general solution.
- Developing a use case for the issue helps dramatically, for this we need to know who, what, and why.
- Who does it affect? (Braille users, Speech users, accessibility developers, nvda developers, etc)
-- This helps to give an estimate on how many users this will help.
-- Also highlights differences in requirements for different users.
- What is the user trying to achieve?
- A step by step of what they expect to do, and the kind of output they expect along the way.
-- Does this need to work with other software? What version(s)?
-- Can an example be provided? Perhaps a relevant test case?
- Why do they want to do this?
- What does it help them achieve?
Can we label this as a regression, a requested change of behaviour, or a requested new feature? Is there a known work around, what are the existing alternatives, or is there any way to achieve this already?
The behaviour of the software has changed, unintentionally. This may mean that a feature has stopped working all together or there may be an error sound, or perhaps a crash.
- How is it triggered?
-- What are the steps to reproduce the bug?
-- What version of NVDA? Good: 'stable', 'next', 'rc', 'release' Better: 'next-13896,5322f3d8'
-- What version of software being used with NVDA?
- What happens when it is triggered, what is the effect?
- Can it be reproduced on another computer by another user?
-- Make sure to note the versions used when reproducing the issue. This can be really help to narrow down incompatibilities between external software and NVDA
This is something that NVDA did not previously do.
- Is this solved by other screen readers? How?
- What is the use case for this?
- Are there any variations on the use case?
- Is it different for speech, braille, or visual users?
Change of behaviour:
- What is wrong with the current behaviour?
- What are the circumstances around the requested change?
- What is the use case, does it differ from the intended use case of the feature?
Summarising the issues periodically / when data collection is done.
It's common that this process of collecting information will result in many comments on the issue. In order to make it easier for someone to quickly pick up the issue and understand it a summary comment can be added. This also serves to re-iterate decisions that have been made throughout the discussion and ensure that everyone is on the same page.