Uploading markdown files of all the chapters

USER Findings by chapter/Part 2 - Project Operations/knowing-your-users.md

@@ -24,7 +24,7 @@ There is a strong focus on what people on these channels say they need. As one i
 
 The “community need” was the strongest pressure on software development in our survey, even slightly larger than the obvious “research need.”
 
-![chart-what-other-pressures-drive-your-projects-work](https://assets.digitalocean.com/articles/alligator/boo.svg "chart-what-other-pressures-drive-your-projects-work")
+![chart-what-other-pressures-drive-your-projects-work](https://raw.githubusercontent.com/simplysecure/USER_project/11f3af7b8365f52dc1878db42733241579ac6e7c/USER%20Findings%20by%20chapter/Part%201%20-%20The%20State%20of%20Science%20and%20Research%20Open%20Source%20Software%20SROSS%20Projects/chart-what-other-pressures-drive-your-projects-work.png "chart-what-other-pressures-drive-your-projects-work")
 
 
 ### Communication channels are structured around the activities of developers
@@ -47,13 +47,13 @@ The pattern of knowing users but not using formal methods or designating separat
 
 Only few projects mentioned thew worked with UX/UI designers:
 
-![has-your-team-ever-included-a-designer](https://assets.digitalocean.com/articles/alligator/boo.svg "has-your-team-ever-included-a-designer") 
+![has-your-team-ever-included-a-designer](https://raw.githubusercontent.com/simplysecure/USER_project/11f3af7b8365f52dc1878db42733241579ac6e7c/USER%20Findings%20by%20chapter/Part%201%20-%20The%20State%20of%20Science%20and%20Research%20Open%20Source%20Software%20SROSS%20Projects/has-your-team-ever-included-a-designer.png "has-your-team-ever-included-a-designer") 
 
 This matches our observation that most projects did not use methods of UX professionals to get to know their users. “Knowing users well” for UX professionals usually implies a process of research: conducting data via interviews, observations, and surveys. They synthesize this data and create formal abstractions like “personas”, “scenarios” or “user journeys”, genres of documents that summarize what they learned about users. None of our projects had such research and representations. If at all, they used low-resource methods of testing existing parts of the software.
 
 However, despite usually not having a single project member tasked with learning about users, most projects had the impression they know their users well. Not a single participant in our survey answered “No” to the question: “Do you feel you have a good sense of who the users of your project are?” 
 
-![do-you-have-a-good-sense-of-who-the-users-of-your-project-are](https://assets.digitalocean.com/articles/alligator/boo.svg "do-you-have-a-good-sense-of-who-the-users-of-your-project-are")
+![do-you-have-a-good-sense-of-who-the-users-of-your-project-are](https://raw.githubusercontent.com/simplysecure/USER_project/11f3af7b8365f52dc1878db42733241579ac6e7c/USER%20Findings%20by%20chapter/Part%201%20-%20The%20State%20of%20Science%20and%20Research%20Open%20Source%20Software%20SROSS%20Projects/do-you-have-a-good-sense-of-who-the-users-of-your-project-are.png "do-you-have-a-good-sense-of-who-the-users-of-your-project-are")
 
 ### Conclusion
 

USER Findings by chapter/Part 2 - Project Operations/prioritization.md

@@ -0,0 +1,47 @@
+# Part 2: Project Operations
+
+## Prioritization
+
+### Introduction, Usability, a competing priority?
+
+Like any other software, prioritizing what to build and who to build it for is an important aspect of directing development and maintenance of open source science & research software. Project leaders and maintainers strongly consider users when it comes to prioritizing what to build.  
+
+Many factors influence what leaders and maintainers prioritize, such as: 
+- the way users engage with a project,
+- project funding, such as grants,
+- the tools used,
+- and the contributors involved.
+
+### Fixing and Adding Features are Prioritized Over Usability 
+
+Usability or user experience almost never take precedence over fixing or adding features. Scientific and Research OSS projects prioritize bugs or issues that impede a user’s ability to operate or use the platform, followed by features and functionality above anything else. We consistently heard across projects that design and usability are not needed as much as fixing the breaking changes. Participants said that usability is  "important" but not a "priority". For example, one respondent who identifies as a designer said:  
+*“UX/UI is not seen as integral to the process. I don’t think it is valued less but not important enough to plan around or prioritize.”*
+
+### User experience and usability tend to be seen as less valuable and irrelevant for scientific work and thus are not prioritized
+
+Some projects perceive design as “prettiness.” For them, design is not seen as furthering the mission of science and as such because of which its design takes a back seat. Alternatively, design is seen as optimization or beautification of a feature which the SROSS community feels is a secondary activity and can be done later. It is the norm for projects to skip past any design stage.
+
+One of the surfacing reasons for UX/UI to take a back seat is to make the most of contributors’ limited time, which is not always in abundance be it salaried staff or volunteers. While this would usually call for an early design involvement, in order to ensure, with low resources that the SROSS is built user-centered from the start, that is not the common case. Typically in commercial/non-open source projects that are resource constrained, design is more likely to be included earlier in the product development stage as a robust and comprehensive design research process helps product teams know earlier which features of a tool to de-prioritise based on user needs. In open source, because design is perceived as either resource intense or the project lack the access to design knowledge or designers, it is skipped and can therefore lead to a longer and less user-informed product development process by way of perceiving design as superfluous to immediate needs.. Typically in commercial/non-open source projects that are resource constrained, design is more likely to be included earlier in the product development stage. A robust and comprehensive design research process helps product teams know earlier which features of a tool to de-prioritise based on user needs. In open source however, it is skipped because design is perceived as either resource intensive or the project lacks the access to design knowledge or designers, and can therefore lead to a longer and less user-informed product development process by way of perceiving design as superfluous to immediate needs. 
+
+Projects consisting of UX staff are able to weave a layer of usability into the fabric of the software. And yet, there are projects that are unable to prioritize usability despite having UX staff. Some see design as an ever evolving, recurring cycle which gets in the way of shipping a usable product to users. It is something that “would change later if designed now”. Could it be that as a software community, we haven’t arrived at a clear language that explains how prioritizing usability and design will have positive impacts to the core of scientific work?
+
+### Prioritization techniques in Scientific OS Software 
+
+Scientific OS projects adopt various techniques to prioritize user feedback like polling, voting, or discussing the priority order directly with users or clients. This is facilitated by periodic community calls, as well as communication and tracking tools like Github andGitter. However, there’s no standard processes, decision making framework for prioritization in scientific OS product development.
+
+There are several factors that impact prioritization:
+
+- Users influence priority by being "involved", "active", "loud" or even simply by the nature of their public reputation.
+- Contributors also drive prioritization in their own way whether they fix a bug, add a feature, add documentation or examples. Since they volunteer their time, they prioritize based on their personal interest.
+- Client and grant relationships affect how user feedback is prioritized and implemented. A grant may prioritize certain issues over others.
+- 'Urgent' and 'easy to fix' tasks and issues are prioritized. We found in a few interviews that an email reporting an easy or quick 'bug' or a 'problem' is prioritized because it can be tackled soon, as opposed to assessing whether or not it's broadly applicable to users or the solution they have is the most human/user centered fix for the bug/issue.
+
+### Conclusion
+
+There is an awareness of accessibility and usability in scientific OS projects. In general, contributors voice the intention to prioritize meaningful design of the software and demonstrate openness to include design into the process, but they lack clarity to do so. This shows that UX is not seen as bad for the project but also there’s less action on it. Sometimes, it can even be a fair rationalization to not prioritize usability when the project funding and sustainability directly depends on realized features for the software and not really the effectiveness of its use. It may be a long journey to normalize usability as a part of the scientific OS development process and not a competing priority. Establishing the purpose and impact of user experience design will be a great start.
+
+**Our recommendation/s:** 
+
+- **Prioritize design and usability of the software from the beginning:** By weaving UX/UI into the design and build of software, project leads and contributors will save time later when responding to adoption and usability issues. 
+- **Create a clear and shared vocabulary around design and usability in OSS:** Grounding the definitions as a critical part of the build process would help shift perceptions and help project leads and contributors prioritize UX/UI. 
+- **Conceptualize and design the feature exactly how it needs to be built:** Since developer time on OS is limited, it is more efficient to design and then write code for it.