Organization: Difference between revisions

Line 4:

There are currently two Teams, but if needs arise, we may create more later, or possible split up existing teams to spread the workload better.

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

=== R&G : Research and Guidance ===

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&G Team is to create the guides 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 ===

Line 19:

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.

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&G team, Scribes should try to write as Accessibly as possible. Of course, developer guides 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.

Line 27:

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!

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 guides. Our goal is to help people, and we cannot help them if they do not know about us!

@@ Line 4: / Line 4: @@
 There are currently two Teams, but if needs arise, we may create more later, or possible split up existing teams to spread the workload better.
-=== R&D : Research and Documentation ===
+=== R&G : Research and Guidance ===
-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&G Team is to create the guides 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 ===
@@ Line 19: / Line 19: @@
 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.
+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&G team, Scribes should try to write as Accessibly as possible. Of course, developer guides 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.
@@ Line 27: / Line 27: @@
 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!
+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 guides. Our goal is to help people, and we cannot help them if they do not know about us!

Organization: Difference between revisions

CRYSTL (talk | contribs)