Organization: Difference between revisions

(One intermediate revision by the same user not shown)

Line 5:

=== R&D : Research and Documentation ===

The main goal of the R&D Team is to create the ~~Documentation~~ you are currently reading, and to inform the direction of the Development Team. Let's push the boundaries of what it means for software to be friendly and usable! There's no way to know what needs to be worked on without testing of existing tools, and keeping notes on it. But additionally, what we are able to share with the world, is what we have written here, in the wiki.

The main goal of the R&D Team is to create the documentation you are currently reading, and to inform the direction of the Development Team. Let's push the boundaries of what it means for software to be friendly and usable! There's no way to know what needs to be worked on without testing of existing tools, and keeping notes on it. But additionally, what we are able to share with the world, is what we have written here, in the wiki.

=== Development ===

The Development Team is for developing software solutions to software problems! We will need designers, artists, writers, translators, and of course, coders, to make this possible. Good software should adhere as much as possible to the goals laid out in [[Operations]]. Let's try to make our work as modular as we can. We want to be able to work in parallel as much as possible to get things done quickly, but we don't want spaghetti code. Cooperation is important! If you're working on something you think might affect what someone else is doing, ask them about it and make sure your not going to step on each others toes.

== Roles ==

Roles are fluid and you are encouraged to try out different roles to see how well you do, and how well you work with your team. You can of course take more than one Role, but do not over-work yourself! Talking to your Team about what roles you think you would do well at, and what types of roles are needed is very important! We all work best when we work together. Remember, the point of these rules is not to create a power structure, but to organize.

=== Role Templates ===

These roles are well documented and therefore are good to pick from. If you think a different role would be helpful or that something is missing here, please bring it up in [https://matrix.to/#/#fassag-general:chat.solarpunk.moe General]! None of these roles are intended to be exclusive to any Team!

* Lens

Lenses help focus the Team. Lenses should encourage, motivate, and direct. Members should have an idea of how they are best motivated, but if not, Lenses should try to help them figure that out. Lenses also function as oversight, to try to catch potential problems before they happen.

* Scribe

Scribes learn and document. Scribes are heavily encouraged to talk to other members of their team to fill in gaps in their understanding. Whether documenting a project the Development Team is working on, or writing for the R&D team, Scribes should try to write as Accessibly as possible. Of course, developer documentation will inherently be a bit more technical, but they should aim to not make things any more technical than it has to be.

* Engineer

Engineers focus primarily on software itself. When implementing user-facing components, aim to follow guidelines we have already written! If nothing exists however, this is something to bring up with your team! Engineers are also very useful for research, as they will be able to understand why something is the way it is, in a way that those who cannot read code will not be able to.

* Designer

Designers have a very important job, as they will be focusing now just on what looks nice, but also on what is safe and accessible. Designers can help with style guides for writing, icons, UIs, or whatever else really. The goal here is to be creative!

* Tester

Testers should try to push the limits and find bugs and edge cases with the software we are working on and studying. Testers should try to also work with disabled people, to get a better understanding of what methods they use to interact with software, to test out different software using those methods.

* Outreach

This is for the bigger picture stuff. Whether it's managing social accounts, putting up posters, or whatever else, the goal is to get people involved, or at the very least, make people aware of our documentation. Our goal is to help people, and we cannot help them if they do not know about us!

@@ Line 5: / Line 5: @@
 === R&D : Research and Documentation ===
-The main goal of the R&D Team is to create the Documentation you are currently reading, and to inform the direction of the Development Team. Let's push the boundaries of what it means for software to be friendly and usable! There's no way to know what needs to be worked on without testing of existing tools, and keeping notes on it. But additionally, what we are able to share with the world, is what we have written here, in the wiki.
+The main goal of the R&D Team is to create the documentation you are currently reading, and to inform the direction of the Development Team. Let's push the boundaries of what it means for software to be friendly and usable! There's no way to know what needs to be worked on without testing of existing tools, and keeping notes on it. But additionally, what we are able to share with the world, is what we have written here, in the wiki.
 === Development ===
 The Development Team is for developing software solutions to software problems! We will need designers, artists, writers, translators, and of course, coders, to make this possible. Good software should adhere as much as possible to the goals laid out in [[Operations]]. Let's try to make our work as modular as we can. We want to be able to work in parallel as much as possible to get things done quickly, but we don't want spaghetti code. Cooperation is important! If you're working on something you think might affect what someone else is doing, ask them about it and make sure your not going to step on each others toes.
+== Roles ==
+Roles are fluid and you are encouraged to try out different roles to see how well you do, and how well you work with your team. You can of course take more than one Role, but do not over-work yourself! Talking to your Team about what roles you think you would do well at, and what types of roles are needed is very important! We all work best when we work together. Remember, the point of these rules is not to create a power structure, but to organize.
+=== Role Templates ===
+These roles are well documented and therefore are good to pick from. If you think a different role would be helpful or that something is missing here, please bring it up in [https://matrix.to/#/#fassag-general:chat.solarpunk.moe General]! None of these roles are intended to be exclusive to any Team!
+* Lens
+Lenses help focus the Team. Lenses should encourage, motivate, and direct. Members should have an idea of how they are best motivated, but if not, Lenses should try to help them figure that out. Lenses also function as oversight, to try to catch potential problems before they happen.
+* Scribe
+Scribes learn and document. Scribes are heavily encouraged to talk to other members of their team to fill in gaps in their understanding. Whether documenting a project the Development Team is working on, or writing for the R&D team, Scribes should try to write as Accessibly as possible. Of course, developer documentation will inherently be a bit more technical, but they should aim to not make things any more technical than it has to be.
+* Engineer
+Engineers focus primarily on software itself. When implementing user-facing components, aim to follow guidelines we have already written! If nothing exists however, this is something to bring up with your team! Engineers are also very useful for research, as they will be able to understand why something is the way it is, in a way that those who cannot read code will not be able to.
+* Designer
+Designers have a very important job, as they will be focusing now just on what looks nice, but also on what is safe and accessible. Designers can help with style guides for writing, icons, UIs, or whatever else really. The goal here is to be creative!
+* Tester
+Testers should try to push the limits and find bugs and edge cases with the software we are working on and studying. Testers should try to also work with disabled people, to get a better understanding of what methods they use to interact with software, to test out different software using those methods.
+* Outreach
+This is for the bigger picture stuff. Whether it's managing social accounts, putting up posters, or whatever else, the goal is to get people involved, or at the very least, make people aware of our documentation. Our goal is to help people, and we cannot help them if they do not know about us!