kemonine
/
lollipopcloud
Archived
1
0
Fork 0
Code Releases Activity

Update 'onboarding-s.o.s.a.s.a.-article.md'

This commit is contained in:
hoodieak 2018-07-11 19:42:08 +00:00
parent 08aa12875c
commit 0b22b6a6cb
1 changed files with 31 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
onboarding-s.o.s.a.s.a.-article.md
View File

@ -1,38 +1,9 @@
## The Lifetime of an Issue/Feature Request
Original location of the article [here](https://medium.com/@novemberninerniner/the-lifetime-of-an-issue-feature-request-f0ae1210e8c2)(link) by [hoodie aida kitten](https://abandoneddoll.neocities.org/)(link).
Original location of the [article (link)](https://medium.com/@novemberninerniner/the-lifetime-of-an-issue-feature-request-f0ae1210e8c2)(link) by [hoodie aida kitten (link)](https://abandoneddoll.neocities.org/).
Greetings and welcome to my onboarding guide to getting started with a Sosasa board. Lollipop Cloud is a project running my methodology for organizing a public-facing transparent development paradigm (that’s a bit of a mouthful) for an open source project.
First, a definition: an issue is an arbitrary term used in technology for making software that means ‘a feature, bug report, or other request for change in software’. Tools like gitea, github, and several other issue tracking tools all exist in open source development git hosting solutions.
So, we’re going to talk about how that works, from the perspective of an issue, or a feature request. Both are basically the same thing, namely an ‘issue’ in the issue tracker of choice for this methodology, which can be github or gitea, gitlab, or any other sort of thing. It might just be trello, an all in one kanban board. Regardless of what type of tracker it is, the landing page for the Sosasa board should give you a link to make an issue in the tracker of choice, or at least a link to the issue tracking frontend of choice.
To clarify, a kanban board is a set of lists, in a visual format, arranged horizontally, with cards or items in each list arranged vertically in the context of the list it is a part of. For our kanban, this means we have lists of issues, each phase containing the list meaning we can tell how far along it is in the process of becoming a reality in the software, in addition to gitea for code management.
First, let’s link to our [documentation board](https://kanban.lollipop.holdmybeer.solutions/project/admin-lollipop-documentation/kanban)(link).
Once we get there, we can make an issue! Let’s try to parse what that means, before we go and do it.
So, if we look at our sosasa board, you can actually see quite a few issues. Every card in the columns is an issue being worked on. The left side of the board is earlier in the process of being turned into a reality, while the right eventually becomes the finish line, the archive where we store completed, functionally complete issues.
So when we make an issue, it needs to be added to the leftmost column, the ‘brainstorming phase’, or just ‘phase 1’.
The purpose of this phase is actually the most accessible: our only goal is to define what needs to change, the improvement to make in the software. This could be ‘stop software from crashing when X’ or ‘make it so the software can do Y’ or even ‘remove Z feature’.
Regardless, we need to put this information in the issue tracker, not just the sosasa board, as the issue will remain the same as the card in the Sosasa board will change and be moved around the board to many different phases and columns. The main purpose of the board, then, is to give you a decent idea of what needs to be accomplished for each card in the board, so you can know what you can contribute to, with your individualized skillset.
In some projects, the issue tracker might be the Sosasa board. some kanban solutions offer enough tools for the user to forgo an issue tracker entirely. Some issue trackers integrate a kanban into the toolset (github being a standout example, github’s projects hold a kanban solution, which is where i originally proposed this structuring to a certain project manager).
Now that we’ve decently explained the process of making a new issue… we need to backtrack. You see, i skipped a step, in a way, which is fine, and your users can choose to skip this step, if they do not have the energy to do the first step, which is to check the archive phase to see if an issue already exists for the topic at hand.
Let’s say a bug is very rare, and we think we solved it already. that issue will already be archived, and its important to reference this issue, or manually add it back to the brainstorming phase, once it is confirmed the issue is still in fact, an issue.
Issues remain in the archive for this purpose, as a single location any user can check to make sure an issue hasnt already been addressed. this is also where ‘wontfix’ issues will go, which are essentially issues determined to be either unable to be fixed, or outside of the scope of the project.
Wow, that was a lot. Let’s take another step back, and make sure we have all the phases understood. an example trello board exists for the purpose of reading up on any phase, manually, so you can refer to it if you are confused when looking at any other sosasa board, for a project you wish to contribute to. I’ll link it here, so you can read it in depth if you choose to, as well as the option for you to look at the image below to see it all in one view, on this [site](https://trello.com/b/Kq1YOpGt/accessiblity-and-social-activism-oriented-development)(link).
I will describe each phase here, so you can read them in depth, if you like, but do not want to use trello or navigate to that site.
Greetings and welcome to my onboarding guide to getting started with a S.O.S.A.S.A. board. Sosasa stands for "Structuring your project for the purposes Of Social Activism and Accessibility". Lollipop Cloud is running my methodology for organizing a public-facing transparent development paradigm (that’s a bit of a mouthful) for an open source project.
Sosasa functions by using a system of phases, that I will now define below. After that we'll explain how you can interact with them, so if you feel like jumping right in, you can skip down past this.
-----
@ -51,7 +22,7 @@ Before we can move past the mockup and design phase, there must be tangible, und
### PHASE 3: POLLING also known as DECIDING IF IT’S READY TO CONTINUE
For large projects, an elaborate polling system exists in my structure. More on that is in the trello and the original article not personalized for this project [here](https://medium.com/@novemberninerniner/the-lifetime-of-an-issue-feature-request-f0ae1210e8c2)(link). If it fails the poll, the issue goes back to Mockup and Design for more iteration, or if it is unclear, it also goes back to mockup and design but means that you must, instead of reworking the idea, clarify what the idea is doing, or what the example issue being resolved is. For smaller projects, like ours, this will be a set of eyes from the main developers.
For large projects, an elaborate polling system exists in my structure. More on that is in the trello and the original article not personalized for this project [here (link)](https://medium.com/@novemberninerniner/the-lifetime-of-an-issue-feature-request-f0ae1210e8c2). If it fails the poll, the issue goes back to Mockup and Design for more iteration, or if it is unclear, it also goes back to mockup and design but means that you must, instead of reworking the idea, clarify what the idea is doing, or what the example issue being resolved is. For smaller projects, like ours, this will be a set of eyes from the main developers.
### PHASE 4: DEVELOPMENT, also known as IMPLEMENTATION
@ -71,15 +42,36 @@ Features fully completed remain in the final phase, so that the issue may be reu
-----
OK, that was a lot of information. I want to sum up, and bring it back together into an understandable call to action, or other ‘how to continue’ statement.
This is a blueprint, of sorts, for how to address decision making in a group-accessible manner, for your community and social media. If you are developing social media software, such as mastodon, or can otherwise support it you will want a public facing posting in a log-like manner to the social media whenever one phase shifts to another, and more in depth during polling and review phases (3 & 5).
OK, that was a lot of information. I want to guide you through the basics of approaching this, now, so you can use this knowledge on the phase system. First, though, if you didn't quite mesh with that, or want to see what this will look like, here's an example of this system of phases, where instead of having tech to be worked on, it has the explanation of each phase in a visual layout, using the site [trello (link)](https://trello.com/b/Kq1YOpGt/accessiblity-and-social-activism-oriented-development)
So the people in charge of your project must use this as a starting point, not as an ending point. Structure your project based in some part on this blueprint, and you will have something more accessible and more able to be influenced by social activism, than if you hadn’t done so.
First, a definition: an issue is an arbitrary term used in technology for making software that means ‘a feature, bug report, or other request for change in software’. Tools like gitea, github, and several other issue tracking tools all exist in open source development git hosting solutions.
That’s where the failsafe in this system resides: the people in charge of the project, be it the core dev, or the core user, can choose to veto things with that influence. In other words, if we compare this to mastodon, the trending tags feature can be vetoed by the marginalized users it is most likely to hurt. If you don't know what that is referencing, read up more [here](https://hoodieaidakitten.dreamwidth.org/453.html)(link). Vetoing an issue simply knocks it back one phase. the leadership can veto based on individual’s concerns, such as the marginalized users, in my example.
Next, let's talk about the core tool we're using. A [kanban board (link)](https://en.wikipedia.org/wiki/Kanban#Electronic_kanban) is a set of lists, in a visual format, arranged horizontally, with cards or items in each list arranged vertically in the context of the list it is a part of. For our kanban, this means we have lists of issues, each phase containing the list meaning we can tell how far along it is in the process of becoming a reality in the software, in addition to gitea for code management.
If you want to know more, and see the original article on this, peek at the original article [here](https://medium.com/@novemberninerniner/structuring-your-open-source-project-for-the-purposes-of-accessibility-social-activism-6b1d7fe6c97d)(link), and for now i will leave you.
So, we’re going to talk about how these two interact, for this project, from the perspective of an issue, or a feature request. Both are basically the same thing, namely an ‘issue’ in the issue tracker of choice for this methodology, which can be github or gitea, gitlab, or any other sort of thing. It might just be the kanban board, since many can cover all the bases of an issue tracker. For us, let’s start by linking to our [documentation board (link)](https://kanban.lollipop.holdmybeer.solutions/project/admin-lollipop-documentation/kanban).
Once we get there, we can make an issue! Let’s try to parse what that means, before we go and do it.
So, if we look at our sosasa board, you can actually see quite a few issues. Every card in the kanban is an issue being worked on. The left side of the board is earlier in the process of being turned into a reality, while the right eventually becomes the finish line, the archive where we store completed, functionally complete issues.
So when we make an issue, it needs to be added to the leftmost column, the ‘brainstorming phase’, or just ‘phase 1’.
The purpose of this phase is actually the most accessible: our only goal is to define what needs to change, the improvement to make in the software. This could be ‘stop software from crashing when X’ or ‘make it so the software can do Y’ or even ‘remove Z feature’.
Regardless, we need to put this information in the issue tracker, not just the sosasa board, as the issue will remain the same as the card in the Sosasa board will change and be moved around the board to many different phases and columns. The main purpose of the board, then, is to give you a decent idea of what needs to be accomplished for each card in the board, so you can know what you can contribute to, with your individualized skillset.
In some projects, like Lollipop Cloud, the issue tracker might be the Sosasa board. Some kanban solutions offer enough tools for the user to forgo an issue tracker entirely. Some issue trackers integrate a kanban into the toolset (github being a standout example in github's projects feature). For us, the kanban board is where new issues will be made, or where we will interact with existing ones.
More on that... we need to backtrack. You see, I skipped a step, in a way, which is fine, and your users can choose to skip this step, if they do not have the energy to do the first step, which is to check the archive phase to see if an issue already exists for the topic at hand.
Let’s say a bug is very rare, and we think we solved it already. that issue will already be archived, and its important to reference this issue, or manually add it back to the brainstorming phase, once it is confirmed the issue is still in fact, an issue.
Issues remain in the archive for this purpose, as a single location any user can check to make sure an issue hasnt already been addressed. this is also where ‘wontfix’ issues will go, which are essentially issues determined to be either unable to be fixed, or outside of the scope of the project.
That’s where the failsafe in this system resides: the people in charge of the project, be it the core dev, or the core user, can choose to veto things with that influence. In other words, if we compare this to mastodon, the trending tags feature can be vetoed by the marginalized users it is most likely to hurt. If you don't know what that is referencing, read up more [here (link)](https://hoodieaidakitten.dreamwidth.org/453.html). Vetoing an issue simply knocks it back one phase. the leadership can veto based on individual’s concerns, such as the marginalized users, in my example.
If you want to know more, and see the original article on this, peek at the original article [here (link)](https://medium.com/@novemberninerniner/structuring-your-open-source-project-for-the-purposes-of-accessibility-social-activism-6b1d7fe6c97d), and for now i will leave you.
Hopefully we can learn, and grow our methods of interaction with this blueprint
@ -89,4 +81,4 @@ thanks for listening
- hoodie aida kitten
Here's the link to more information on the original creator of this system, [here](https://abandoneddoll.neocities.org/)(link).
Here's the link to more information on the original creator of this system, [here (link)](https://abandoneddoll.neocities.org/).