Tech Ops Reorganization

PROPOSAL - Technology Operations Group Reorganization

Bottom-Lined by Philip Daian

Basic Ideas / Guiding Principles

The Technology Operations group has always and currently operates as a coalition of technically-savvy members working on individual or group projects towards the end goal of furthering the web and technology presence of the Occupy Wall Street movement in New York City and nationally. As the organization has grown, it becomes more difficult to reconcile the needs of transparency and openness that overarches the Occupy Wall Street movement with the practical need for productivity and development which stems from an autonomous, ad-hoc, non-inclusive leadership structure. This proposal aims to provide a balance between productivity and transparency with as few sacrifices as possible. Furthermore, the proposal is designed to formalize procedures and divisions already in place in the working group in order to ease the adoption of the proposal and not disrupt current or planned projects or public relations. The following proposal has been modeled after a combination of the New York City General Assembly and the current working-group model within the Occupy movement.

“Political Off-Loading”

Because most productivity in the Technology Operations group is concentrated outside of the Tech Ops meetings, this document will attempt to off-load all politics and debates about the directions or actions of projects onto the Tech-Ops meetings. This will ensure that, for the remainder of the week, projects are able to be productive with complete autonomy over daily decisions within the scope of the proposals submitted at these meetings.

Basic Divisions

The Technology Operations group will be divided into groups based on projects currently being developed by the members of that group. These projects will then operate as autonomous units with a potentially hierarchical leadership structure and no definitive requirement of transparent communication. Each project must have a protocol for new users to transparently and openly join the project and thus be included on the vast majority of internal project communication. The structure of the group can be created as needed, with no guidelines other than those enforced in this document, and is determined by the founding proposal of the group.

Project Requirements and Proposal Process

In order to maintain or start a project with the OWS Tech Ops group, a project proposal must be submitted at one of the three weekly meetings within the group. Alternatively, off-site members of the group can start a project through sponsorship of an on-site member who is willing to bottom-line the proposal in one of the group meetings. A submitted proposal, in writing with copies for all attending members, must be made detailing the project. This proposal must include the proposed point person(s) of the project, the internal organization of the project (including any hierarchies or communication channels used by the project), the scope of the project, the goal of the project, any implementation details relevant to the user experience or public aspect of the project, any collaborating groups involved in the development of the project, and a list of initial members of the project. The proposal must also include steps for joining a project, any training or other barriers to entry a project may present, and any ongoing requirements for continued membership in a project. These barriers to entry and requirements can be modified as the project progresses, but any modifications must be included in the weekly report-backs (see below) and are thus subject to revocation. All new projects must also agree that all code, data, records, and other output from the project will be completely open-source and/or property of the NYCGA and TechOps. This is to ensure that should a project or point person part ways with the group, the results of the project are not lost. Once a project is approved by achieving group consensus, the proposal (with any modifications required for consensus) is submitted to a central database on wiki.occupy.net, which will contain the proposals and current status of all the projects within Technology Operations.

Each project will also require a weekly report-back at any open Tech Ops meeting. This check-in can be completed in one of two ways:

1. Verbal: The project point-person (or a delegate of the point person) can verbally report-back about recent developments and decisions regarding the project. If anyone else present has additional points of information regarding the project, those will be welcome additions to the report-back. As the verbal report-back is given, the wiki page for the project should be updated live by a scribe to reflect the report-back along with the meeting minutes. (Ravi: or the meeting minute taker will take notes and include them into the project's wiki page.)
2. Written: The wiki page dedicated to the project must be updated before a meetings with a log of all the progress and decisions the project group has made. A central facilitator at each meeting will read the new, reported progress of all the current projects, and any objections to any progress or decisions can be raised.

Regardless of the report-back method, it must be as comprehensive as can reasonably be expected while remaining clear and concise. While these are report-backs and not proposals, the course of these projects is of interest to the group as a whole and the group will therefore pursue a variation on the consensus process along with each report-back. After the report-back is spoken or read, stack will be opened for any clarifying questions or concerns. If the point person or representative of the project is present, these issues can be addressed directly. If not, someone will be responsible for following up with that individual before the next meeting. If anyone at the meeting has strong moral or ethical opposition to the direction a project is going, it is their right to block the continuation of the project along its current path. However, unlike the typical consensus process, in this case, the burden of consensus is on the blocker. The blocker is obligated to explain the block and offer proposals that would lead to the removal of the block. These proposals may include assignment of a new project point person, revised project goals, revised entry requirements, or even the complete withdrawal of Tech Ops sponsorship of a certain project. If the blocker cannot find a modified (90%) consensus to support their block and implement their suggestion, the project is allowed to move forward. Any such incidents will be recorded in the minutes of the meeting, to be published on nycga.net/groups/internet under “Documents”.

Please note that existing projects will not be required to obtain consensus to begin, but will have to submit a form containing all their information for the central database and follow the same weekly report-back procedure.

Point Person Requirements, Protocol, and Procedure

Internally, projects can be run at the discretion of the founding document, with few notable exceptions. The project does not have the right to remove or exclude members from the project without approval (90%) of the weekly meeting without risking approval of their project by Technology Operations or facing forcible reorganization through methods consented upon within the group meeting. Furthermore, point persons or a point person must be assigned and tasked with the responsibility to provide or delegate report backs which are, to the best of their knowledge, accurate and comprehensive. Internal communication can be done through any means necessary (e-mail, SMS, forums, Wiki, IRC, etc), specific to the project. If a project requires the participation of working groups that are not the Technology Operations group, the project point persons will be responsible for delegating or establishing contact with other groups in order to forward the goals of the projects as approved by the Technology Operations meetings. The project point person must be listed on the project's page on the centralized project database.

Inter-Project Working Relationships

If two projects wish to collaborate on one effort, specifications should be written by the two groups for collaboration, with delegation to do so provided either informally and internally or by the founding document of the project. Such specifications should include processes for facilitating inter-group meetings, inter-group communication channels, required API’s, or any materials necessary to the interoperation of the projects. These specifications must then be approved by both projects and presented to the meeting in a report-back following the same procedure as the weekly progress reports from each process.

Closed / Open Aspects of the Proposed System

Weekly report backs in open, public technology operations meetings ensure the openness of all project progress and direction. Joining projects or viewing available projects is open and centralized through contact points on the project database on the wiki, and vetoing work and decisions made by the point persons is possible with the above outlined veto procedure. Project approval is required at open meetings, and all overarching, non-project-specific group decisions must still be made at the Tech Ops Technology Operations meeting.

Project productivity, internal communications, and implementation details are left to the discretion of the founding members of the project and can be continually revised per the leadership document of the group. These details can only be changed by non-members of the project through the votes on the report backs on weekly meetings. This is currently more closed than the semi-accountable system we have now, but trades transparency for productivity, resource use, and the ability to “get shit done.”

Cost/Benefit Analysis of the Transition

• Cost: Defining project point persons for all internal projects within the tech group, as well as all inter-group projects decreases horizontality within the technology operations group. This is addressed through the weekly report-backs and overarching decisions provided through the open, public, Tech Ops meetings. In addition, as most projects are already managed under an informal leadership, hierarchical model, formalizing this procedure will result in a minimal loss of horizontality, although adopting this procedure does preclude proposals to increase horizontality within the group through fully-open communication. Furthermore, the barrier to starting and maintaining an approved project is increased due to the need for weekly report-backs on project progress, as well as the need to submit and maintain a detailed proposal to the centralized project database. We will attempt to alleviate this burden by automating project creation through electronic tools, bottom-lined by Philip Daian. Lastly, a clear protocol for adoption in user-friendly terms will be provided to ease entry barriers to project maintenance and communication.

• Benefit: The ease of involvement in the Technology Ops group will be increased by a centralized project database, providing easy ways to view all running projects, their progress, and the people to contact to get involved. Internal productivity will be increased, as the amount of time required to maintain report-backs is less than the amount of time spent ensuring transparency within a particular project. Furthermore, projects are already expected to do basic report-backs, so formalizing this procedure results in minimal added internal overhead. Lastly, the transparency of the group will see a marked increase as project progress and existence is centralized and publicly available.

• Conclusion: The benefits of transparency, ease of involvement, and productivity outweigh the minimal (and debatable) loss in horizontality and barriers to project entry.

Disciplinary Action and Enforcement

Disciplinary action involves the violation of the actions listed above under actions which may have project support revoked. In order to revoke project support, modified consensus at a Tech Ops meeting is required. One member of the group will be selected to be the watchdog of the group, ensuring that all projects comply with their maintenance in both the centralized database and the weekly report-backs on the project section of the Wiki. This member will raise any concerns as an agenda item at the Tech Ops meetings, and the issues will be discussed and consented upon by the group.

Quorum

If a meeting has less than 10 attendees, any votes pertaining to approving or disapproving of specific projects must be postponed to the next meeting.

Notes for Consideration

Below, add notes that you think might help refine this proposal, but that you are not ready to integrate into the proposal itself yet

1. As I think more about all this, I wonder if we would be better off keeping the project database on our sub site (internet.nycga.net or someday tech.nycga.net) rather than the wiki. Reasons below:
   1. This seems like it might be a much more useful format to track recurring report-backs, etc rather than the wiki. Blog posts in certain categories would lend themselves well to this.
   2. It would be more repeatable by other groups, if we come up with a good blog-based implementation of this
   3. Ron has already started doing project/team tracking on that site
   4. The permissions and editing options are more configurable and the authors of report backs are more clear.
   5. Commenting is easier
   6. This would integrate far better with the nycga.net site which feels more appropriate than commandeering with wiki for this purpose.
   7. Tech Ops would retain more control over the list as opposed to it being on a completely open wiki that anyone can mess with
2. Is it really ok to allow written-only report-backs? How does this allow clarifying questions and concerns to be addressed in an efficient way? But if we don't allow this, we are forcing the point person (or a delegate) to attend at least one meeting per week. Is this reasonable? What is a project has had a very slow week and nothing much has happened? Maybe report-back frequency is up to the project point person, but there is some way for the group to call on a project to report-back on demand?