kemonine
/
lollipopcloud
Archived
1
0
Fork 0
Code Releases Activity

Merge branch 'sosasabranch' of jmf/lollipop-docs into master

This commit is contained in:
jmf 2018-07-16 19:02:09 +00:00 committed by Gitea
parent 946fd9366f edef86e122
commit e25c75397f
1 changed files with 33 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,84 +1,55 @@
## The Lifetime of an Issue/Feature Request
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/).
# The Lollipop Cloud Project's Issue Reporting and Feature Requesting Process
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.
## Definitions
(or skip to the [Introduction](#Introduction) below.)
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.
* __Kanban:__ A [kanban board (link)](https://en.wikipedia.org/wiki/Kanban#Electronic_kanban) is a means of visualizing the workflow of a project or organization. It is presented as a set of lists arranged horizontally by status, with each status containing vertical lists of cards (or items).
-----
* __SOSASA:__ "Structuring your project for the purposes Of Social Activism and Accessibility," or SOSASA/sosasa, is a kanban-based methodology for tracking issues and feature requests, and described in detail by creator hoodie aida kitten in [this SOSASA methodology Medium article (link)](https://medium.com/@novemberninerniner/the-lifetime-of-an-issue-feature-request-f0ae1210e8c2).
* __Issue:__ An issue is a vague word to describe anything you'd like to change about a project. This could be any problem, such as an error message or an unexpected behavior (a "bug"), an unmet accessibility need, inadequate documentation, a request to improve an existing feature, or a request for a new feature.
### PHASE 1: BRAINSTORMING, also known as IDEATING A NEED TO BE MET BY THE SOFTWARE
## Introduction
Brainstorming. This is the vaguest and hardest to pin down phase, and that’s something that can’t be changed. This phase is where the feature or goal of a feature is laid down, and the proverbial ‘need’ to be ‘met’ by the software is ideated and worked on. This is before we even approach the design of software to address the need in question, purely speaking in terms of what needs to be accomplished.
The Lollipop Cloud project has adopted the SOSASA methodology for tracking issues and feature requests. SOSASA functions through a system of phases, which we have tailored and outlined in the [Phases](#phases) section below.
An issue will be created in the github or project tracker of choice at this stage to be used for the entire lifetime of the feature or issue in question, both to log progress and make it easier to track it from a user perspective.
The Lollipop Cloud project has a [sample kanban board here (link)](https://kanban.lollipopcloud.solutions/project/admin-template-kanban/kanban).
### PHASE 2: MOCK-UPS AND VISUAL DESIGN, or DECIDING HOW IT WILL LOOK AND HOW IT WILL WORK
## How to request a feature or report an issue
You will need to create an account and [login (link)](https://kanban.lollipopcloud.solutions/login?next=%252Fdiscover) to the [Lollipop Cloud project's kanban page (link)](https://kanban.lollipopcloud.solutions/).
This is where the feature is ironed out into a set of goals to be accomplished, such as: API endpoints, UI frontend menus and the like, mocking up designs to implement, and laying out the actual goals being addressed and worked towards with the feature.
* For documentation issues, go to the [kanban board for documentation (link)](https://kanban.lollipopcloud.solutions/project/admin-lollipop-documentation/kanban/).
Before we can move past the mockup and design phase, there must be tangible, understandable visualization of the intended end result. As long as the user or activist in question can look at your diagrams or mockups and go ‘yes, I understand what is being accomplished’, this phase has been addressed.
* For code-related issues, go to the [kanban board for code (link)](https://kanban.lollipopcloud.solutions/project/admin-lollipop-cloud/kanban/)
### PHASE 3: POLLING also known as DECIDING IF IT’S READY TO CONTINUE
Click the `+` sign at the top of the brainstorming column. (Any `+` button will work, just ensure the drop down menu in the middle of the popup window has `Brainstorming` selected from all the [Phases](#Phases) in the list.)
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.
Provide as many details as possible to describe the issue or new feature. Attaching screenshots or links to examples are very helpful.
### PHASE 4: DEVELOPMENT, also known as IMPLEMENTATION
**Please note:** You do not need to be an expert in the technology to contribute. Your best effort to describe an issue or new feature in your own words is enough, and we are grateful!
At this point, developers or builders take over the proverbial issue and attempt to put the mockups and designs into practice. If they cannot do so, for whatever reason, the issue goes back to mockups and design. If they do manage to do so, it goes to the next phase, ‘review’.
## Phases
### PHASE 5: REVIEW, also known as MAKING SURE WE ACCOMPLISHED OUR GOALS
### Phase 1: Brainstorming
During brainstorming, the issue (bug) or feature request is defined. An issue will be created in the [Lollipop Cloud project's kanban page (link)](https://kanban.lollipopcloud.solutions/), and its status can be tracked here at any given time. At this time we use two separate boards: [documentation (link)](https://kanban.lollipopcloud.solutions/project/admin-lollipop-documentation/kanban/) and [code (link)](https://kanban.lollipopcloud.solutions/project/admin-lollipop-cloud/kanban/).
The review phase is the most difficult phase to understand, because it’s also the most important. At this phase, there is another another set of eyes put on the project again. This time, it determines how many phases the feature goes back so that it can get the work it needs to be ready for widespread use.
### Phase 2: Mock-ups or visual design
This is where the details are described or visualized. Details can involve physical appearance such as user interface (UI) or wireframes, or can be an outline of actions, such as desired feature behaviors.
### PHASE 6: ARCHIVAL, also known as KEEPING TRACK OF ALL THE THINGS WE DID
### Phase 3: Polling or appeals
Once a mock-up is created, participants can vote in favor or against the mock-up, and provide feedback. Polls can be formal (using a tallied voting tool) or informal (providing feedback in favor/against), and feedback can be anything, including suggestions for clarification or improvement.
If changes are needed, the item goes back to the mock-ups/visual design phase for reworking. If no changes are needed, the item proceeds to the next phase.
Features fully completed remain in the final phase, so that the issue may be reused if it needs to be bumped back to an earlier phase to address a bug or user concern, such as user safety.
### Phase 4: Development or implementation
Contributors (coders, writers, artists, etc) attempt to put the mockup or design into practice. If problems arise, the issue goes back to the mockups and design phase for discussion. Once the item is implemented, it proceeds to the next phase.
### Phase 5: Review
At this phase, the implementation is evaluated to determine if it meets the goal that was defined during the brainstorming phase. If the goal was not met, the item moves back to an appropriate phase for reworking. If the goal was met, the item proceeds to the next phase.
### Phase 6: Archival
Completed items are archived so they may be revisited for bug tracking and continuous improvement.
## Conclusion
We hope this will provide the greatest transparency for the Lollipop Cloud Project, and lower the barrier for participation and contribution.
-----
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)
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.
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.
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
I think we can make good things happen, if we meet these goals, after all.
thanks for listening
- hoodie aida kitten
Here's the link to more information on the original creator of this system, [here (link)](https://abandoneddoll.neocities.org/).
If you have questions or feedback about the Lollipop Cloud Project's adaptation of SOSASA methodology, please [contact us (link)](https://lollipopcloud.solutions/page/contact). If you have questions about SOSASA, please contact the methodology's creator, [hoodie aida kitten (link)](https://abandoneddoll.neocities.org/).