Outreachy report #39: November 2022
Our team has started to plan our goals for 2023. This has been a great opportunity to wear my systems analyst hat.
Traditionally, we’re taught to see the world through the lenses of reductionism thinking. That paradigm defends that the world can be split in small parts, and that analyzing those small parts are the simplest way to understand what we comprehend as the whole. This rationalization and compartmentalization of makes it difficult to visualize relationships and the effect those relationships have on the whole.
Outreachy, however, often deals with what academics call messes or complex situations. They have interdependent causes and consequences. They involve a huge scope with ample impact. We’re required to reconcile multiple and sometimes conflicting perspectives. We model solutions to a great level of uncertainty.
Reductionism is not necessarily a worse paradigm—that’s still a valid problem solving tool. For example, when our website certificate expired last week, saying that someone forgot to renew it isn’t a wrong conclusion. But, at an organizational level, it’s not helpful to say “person X is the sole reason why this happened because they forgot to renew the certificate”. It’s easy to deflect from the responsibility of changing processes and whole systems when you can just blame one of the parts. Industries like aviation prefer to model risk using an approach called “Swiss cheese model”—an incident happens when multiple flaws in multiple layers of systems align.
If you think of our website as one system that’s part of Outreachy’s bigger organizational system, you can get to an even more interesting set of questions with short and long-term implications:
- Is this an isolated incident or does it have implications for the Dokku project as a whole?
- Who has server access to intervene when something like that happens? Who is trained to respond to an incident like this?
- Do we actively monitor the health and integrity of our systems? How? Who has access to those systems reports?
Systems thinking is an excellent paradigm to adopt when modeling solutions for Outreachy because the same eyes you use to identify oppressive institutions and social structures in the technology industry of someone’s country can be trained to make our processes and policies more expansive and human.
Another example we’ve discussed this month was time commitment checking and validation. We trust our applicants to tell the truth when they say they’ll quit a full-time job if selected as an intern. If we don’t trust our applicants, asking for additional documentation does nothing but transfer our trust to something or someone else. Can we trust that someone else? Do we trust them? The most fundamental problem wouldn’t be solved.
That’s why we model solutions for mitigation. We can’t eliminate this problem with a single procedure. Humans lie and they can be very creative when they lying. But we can take steps towards improving this complex situation. We can invest in our relationship with mentors and coordinators and ask them to tell us when they feel there’s something wrong. We can encourage Outreachy interns to embrace a culture of communication, transparency, and openness. We can monitor intern feedback since the beginning and intervene when we recognize something isn’t right.
Our systems are based in relationships and the trust we have in them—reducing them to their parts strips them of their context and can lead us to wrong direction.
My last example is our knowledge management system. Our internal documentation is composed of a private wiki, access-controlled pages on the website, a couple of private live editing documents, and some kanban boards. We often struggle to figure out which documents represent the latest version of our work. We currently don’t have a permanent single source of truth—it changes with context and time.
It may be easy to acclimate a couple of people to the quirks of this knowledge management system, but the more we expand, the more difficult it is to onboard new people. When Omotola joined our team, I came up with a set of principles to guide our training sessions. They were:
- Context-based: Training changes with our yearly timeline. If someone arrives during our initial application period, we’ll introduce them to relevant tasks as they emerge organically in that period of time.
- Curiosity-based: I encourage newcomers to be curious about our history and our systems. They’re encouraged to ask questions about our structure, our processes, decisions we’ve made throughout our history.
But as time went on, I realized our wiki wasn’t as accessible as I wanted—Git and GitLab are intimidating when they’re not part of your day-to-day workflow, and our wiki wasn’t being updated as often as I’d like. In addition to that, the format itself became suffocating—the sidebar is difficult to use, the structure itself is not intuitive. I worry about adding another member to our team and providing them insufficient documentation.
The most challenging thing so far has been finding an adequate open source platform to host and manage our “single source of truth”. But on the more theoretical side of things, a systematic framework for documentation has been quite helpful in categorizing and understanding our current set of documents.
(I’d maybe add a “state-oriented” type since part of the challenge of working with an asynchronous team is letting people know what’s been done and what needs to be done.)
I’ve been also pondering about our documentation culture as a whole, and reading a lot about handbook-first approaches to create a knowledge management system proposal for Outreachy. Considering some of the conversations we’ve had as a team, the KMS design should be:
- Internal
- Private-first
- Procedure, policy, and timeline-focused (“How?”, “Why?", “When?”)
- Information, understanding and status-oriented
And these are some of the goals I have in mind:
- Guide onboarding
- Facilitate policy making and reviewing
- Support day-to-day operations
- Strengthen asynchronous communications