Community Guidelines (Attribution)

Examples of behavior that contributes to creating a positive environment include:

• Be friendly. Use welcoming and inclusive language.
• Be empathetic. Be respectful of differing viewpoints and experiences.
• Be respectful. When we disagree, we do so in a polite and constructive manner.
• Be considerate. Remember that decisions are often a difficult choice between competing priorities. Focus on what is best for the community. Keep discussions around technology choices constructive and respectful (e.g., do not say “real programmers use vim”).
• Be patient and generous. If someone asks for help it is because they need it. When documentation is available that answers the question, politely point them to it. If the question is off-topic, suggest a more appropriate online space to seek help.
• Try to be concise. Read the discussion before commenting in order to not repeat a point that has been made.

Triumvirate

The triumvirate are responsible for presiding over the board of directors. They must organize weekly board meetings (when relevant) and carry the votes after letting the directors discuss the issue. They must also overlook the development of projects as well as the work done by other officers. Open Code @ MIT will have a minimum of three distinct officers:

• President: The President is additionally responsible for representing Open Code @ MIT externally in MIT and ASA meetings as well as relevant meetings. The President must be a current MIT student.
• Vice President: The Vice President is additionally responsible to take the roles of the president when the president is busy or unavailable. The Vice President is also responsible for sending relevant reminders for executive meetings. The Vice President must be a current MIT student.
• Treasurer: The Treasurer is additionally responsible for managing the finances of Open Code @ MIT. The Treasurer must approve all disbursements from Open Code @ MIT’s accounts, including reimbursements to members. The Treasurer must be a current MIT student.

Officers

In addition to the triumvirate, Open Code @ MIT has other roles designated as officers. At least half of Open Code @ MIT officers must be distinct current MIT students.

• Social Chair: The Social Chair is responsible for organizing social events for the members of Open Code @ MIT as relevant in the “Events” section.
• Outreach Chair: The Outreach Chair is responsible for organizing guest talk events for the members of Open Code @ MIT as relevant in the “Events” section.
• Web Chair: The Web Chair is responsible for keeping the website, resources, and mailing lists updated with the information relevant to the members of Open Code @ MIT.
• Hosting Chair: The Hosting Chair is responsible for managing the servers owned by Open Code @ MIT.
• Publicity Chair: The Publicity chair is responsible for publicizing and creating posters for the events organized by Open Code @ MIT.
• Inclusion Chair: The Inclusion Chair is responsible for organizing events about inclusion and accessibility in open software and technology for the members of Open Code @ MIT. In addition, the Inclusion Chair is responsible for keeping Open Code @ MIT an inclusive space and events are inclusive for all students.

Membership

• Any member of the MIT community is eligible to become a member of this organization. One is considered a member of this organization in any given academic term if that person is subscribed to the mailing list.
• The organization’s membership will at all times consist of at least 5 MIT students and be more than half MIT students.
• This organization will not discriminate based on any characteristic listed in MIT's Nondiscrimination Statement.
• If this organization charges any monetary dues, there will be exceptions made for students that cannot afford these dues.

Elections

• Elections of officers shall occur annually during the final weeks of the spring term.
• Any member of this organization is eligible to run for any office.
• Quorum for elections is two-thirds of the number of officers.
• Voting will be conducted in the form of Rank Choice with voting members ranking their top two candidates out of all running candidates in the election; this applies per chair.
• Any member is elected if that member wins a majority of the voting members.
• If more than two people are running then, until one person wins a majority, the person with the fewest votes is dropped from the ballot and votes are recounted based on valid rankings. If no majority is reached after this then a new election is conducted for that chair.
• The term of office runs from one election to the subsequent election.
• Officers may be removed by a two-thirds vote of the members with the quorum being the same as for elections.

Meetings

• Officers meetings should be held with board meetings every week.
• Meetings shall be presided over by the triumvirate.
• All relevant decisions (unless otherwise stated in this document) shall be made by a majority vote of all members present.
• Quorum for a meeting shall be half of the number of officers.

Projects

We have come up with a simple way to manage projects and will encourage this method in the projects we maintain. Each project will have directors (usually one) and developers (one or more). Our goal is to create a collaborative and stress-free environment. Below, there are descriptions for each of the roles, but we understand that people get busy or things might not work as they were planned. If that’s the case, feel free to talk to any of the triumvirate or the officers.

• Director: Project director will be responsible for tracking and updating the status of the project and should have technical skills to mentor and help developers. The director should also assign tasks to developers and occasionally check-in on them. The director may refer to someone else knowledgeable about the project when they are busy with other responsibilities or in need of assistance. It is possible that the director also is a developer of the project. One person could be a director for multiple projects.

• Developer: Anyone who occasionally or actively contributes to a project, whether that be through code, music, art, translation, design, or testing. Developers are responsible for communicating what tasks they are willing to work on and should, to the best of their abilities, estimate when they can get it done. In case a developer needs help or more time, or no longer can do the task, or wants to withdraw from the project, they should reach out to the project’s director(s).

When a director wants to withdraw from their project, they should appoint (based on contributions and knowledge about the project) one of the developers who is willing to take on the role. This must also be approved by the board of directors. In case no appointment is made, the board of directors take this responsibility to replace the director or mark the project as stale for the time being.

Board of Directors

The board of directors refers to the group of people who are a director in one or more projects. When there is a new project that hasn’t been started yet or there is a need for a director in another project, it is possible that the board of directors will be looking for a new director. In this case, an announcement will be sent to the mailing list and members who are willing to take on the role will need to reach out and talk to the board of directors. The priority will be given to those who have contributed in the current or the past projects, but the interest for the project who needs a director will also be greatly considered. The decision to appoint a new director or to dispose of a previous director must be with the majority of the board of directors as well as the majority of the triumvirate (president, vice president, and treasurer).

Events

We are passionate about meeting the members and making it possible for the members to meet with each other, so there are a few types of events we have planned. These events are planned to happen weekly and might be part of the weekly board meetings. Any member can apply to organize any type of event (specified below or otherwise) under the supervision of the social chair.

• Share What You Know (SWYK): In this event, a member (or multiple members) will be sharing their knowledge on a specific topic. This could be related to a programming language (e.g., “how template programming works in C++”) or a framework (e.g., “how to implement REST API in Flask”), or anything that could be useful in development of the projects (e.g., “how to set up your IDE for better productivity”).
• Tech vs Tech (TvT): There are many open source technologies, and sometimes it is hard to choose which one to use. In Tech vs Tech, members will be given the opportunity to learn about two or more technologies and discuss which ones are better in which situations.
• Guest Talks (GT): We will sometimes invite others to give a talk about a topic they are specialized in. The guests could come from the open source community, MIT professors, or MIT alumni.
• Project Review (PR): When a project hits a major milestone, the director and the developers might request a project review, which serves as both a celebration and an opportunity to receive feedback from other members.
• Hall of Shame and Fame (HSF): There is a lot of software to learn from. Some of them are well-done and some are not. In this event, we will collect some examples of both sides about a few topics and present them.