## 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/).

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.

-----


### PHASE 1: BRAINSTORMING, also known as IDEATING A NEED TO BE MET BY THE SOFTWARE

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.

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.

### PHASE 2: MOCK-UPS AND VISUAL DESIGN, or DECIDING HOW IT WILL LOOK AND HOW IT WILL WORK

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.

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.

### 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 (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

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’.

### PHASE 5: REVIEW, also known as MAKING SURE WE ACCOMPLISHED OUR GOALS

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 6: ARCHIVAL, also known as KEEPING TRACK OF ALL THE THINGS WE DID

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.




-----



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/).