Sosasa onboarding article contribution guide

full article added, rewritten for Lollipop Cloud specicifically.

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

@@ -0,0 +1,92 @@
+## 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).
+
+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.
+
+
+-----
+
+
+### 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](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.
+
+### 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 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).
+
+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.
+
+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.
+
+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.
+
+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](https://abandoneddoll.neocities.org/)(link).