Structuring your Open Source project for the purposes of Accessibility & Social Activism
Source (for the purposes of)
well that’s a mouthful, ain’t it?
let’s break down what i mean, before we begin. whenever you embark on an open source project, your goal, at least theoretically, is to allow anyone to contribute time or effort to making your project a reality, be that project a social media implementation, a little drawing, or whatever it may be.
so, for a project like social media software, the ability for users on that software to interact with the development of the project in question is a near-necessity
if you don’t, you will end up with random users on your software upset at the software in question, because it changed, and they don’t like how it changed
that’s not a very good situation to be in, all things considered. it means that your users are not only unhappy with you, they’re using the very thing they’re unhappy with, to express that they are unhappy
all of a sudden, your user base is flaming, proverbially speaking, and spewing that flame wherever they might be able, to try to get it out and over with, so they can move forward, and go back to being happy users on a software they like
so how can we avoid this terrible outcome, and keep the fire from starting in the first place?
first off, i have an example for you to browse, using trello to implement the necessary ‘phases’ of development
and below, i have attempted to list these phases for an alternate method of browsing
Phases of Development
- Brainstorming (vague, find a need or find a place software may improve things)
- Mockups and Design (pinning down what the feature will do, drawing up diagrams and UI in addition to describing each of the actions that must be taken to implement the feature in question)
- Polling and Appeals (public decides whether or not feature is up to task and good enough to begin implementation. requires X% of the public opinion to be in favor. voting options are ‘begin implementation’, ‘scrap and brainstorm again’ or ‘unclear, needs better mockups or design’)
- Implementation, code and development (the actual down to business code work to get the feature implemented)
- Review phase (second bout of polls, checking in to see if the feature has met its goals)
- Fully Implemented (a list of all achievements thus far. when bugs are brought to the attention of the fork, these fully implemented features are kicked back to mockup and design phase so they can be addressed)
this is not the entire system i have designed, however, and that is part of why it’s such a difficult topic to address
for such a system to be accessible, and properly allow for social activism to work in it’s favor, it needs some public logging, and i would suggest this be implemented into the phase system itself, preferably with some sort of social media as the output of each log entry, in the form of a post on the social media.
in our example, we will use pleroma or mastodon as the social media of choice, because that is where our users are, and it also means we can directly implement the polling feature into the social media the logging would utilize, and leverage user accounts on that platform as the account that verifies votes.
this blog post also goes into depth on how to implement polls for our purposes https://medium.com/@novemberninerniner/polls-general-requests-and-social-activism-7ba51eebddaa
so we’re starting to get a blueprint laid out. we have a system of phases to track how far a feature is in development, we have a system to poll the users and allow for activists to influence software’s creation directly through public opinion, and we have a visual representation of all of these, in kanban boards like trello or Taiga.io or Kanboard or more. ( kanban open source software: https://opensource.com/alternatives/trello )
so now we need to define what our logging tool. we’ll use a fediverse account, preferably on some software with proper polling features already implemented (although as far as i know, this does not exist yet, whichever software first implements it can earn the claim)
the logging tool will
A) post when a new issue is created on the issue management tool (such as github, gitea or gitlab)
B) post when an issue is moved from one phase to another
C) post polls when polling phases are entered, with a timed aspect so that users have a defined window during which they may participate
should all of what i’ve laid out thus far be enacted, not only do we have an accessible, easy to glance and parse frontend for users in the kanban board, we also have a social media compatible endpoint for user activism to influence the development of the software, and sway features in favor of what is most important, whether that be a user safety issue, an accessibility issue, or other priorities that activism is most likely to find that might otherwise be missed
i hope i’ve convinced you of the importance of a structure to the process of feature development, or at least informed you on how social activism might be better involved in open source development
my final point is a polite request, spoken to anyone attempting to enact this system i have laid out
please, when using such a system, allow room for an authority to veto things. vetoing an issue would set it back one phase exactly, and be a very high-profile action, with public opinion being involved in some manner, preferably via logging and a poll to gauge public opinion of the veto in question
it is also worth noting this is a very high level overview, meant as a starting point, or template of sorts. the idea is that it provides some context and flow for an approach to project management.
that said, the needs of projects can and will vary, the details of how you put this to practice are up to individual projects
that’s about all i have to say
thank you for listening,
- hoodie aida kitten.
here are some links to support me if you wanna send me a few bucks or support my work. also now this article is over on dreamwidth where i will be staying and putting my future work. dreamwidth supports RSS and atom, which medium doesn’t.