\documentclass{article} \usepackage[top=1in,bottom=1in,left=1in,right=1in]{geometry} \title{\bfseries Constitution of Student-Run Computing and Technology at George Mason University} \date{Date drafted: \today} \author{\texttt{srct@gmu.edu}} \setcounter{secnumdepth}{0} \usepackage{hyperref} \usepackage{color} \pagenumbering{gobble} \begin{document} \maketitle %%%%%%%%%%%%% %%% SECTION 1: Name of Organization %%%%%%%%%%%%% \section{Article I --- Name of Organization} This student organization shall be named Student-Run Computing and Technology (SRCT). The website for SRCT shall be located at \url{srct.gmu.edu}. %%%%%%%%%%%%% %%% SECTION 2: Purpose of Organization %%%%%%%%%%%%% \section{Article II --- Purpose of Organization} Student-Run Computing and Technology (SRCT) will seek to enhance student computing at Mason. SRCT will focus on establishing and maintaining systems which would provide specific services to the general Mason community. \subsection{Open Source} SRCT is strongly committed to the principles of Free and Open Source Software, and it is recommended that software used by or created by SRCT be Free and Open Source. However, we do acknowledge that there are times when proprietary software is more practical or more appropriate, and so our committment to open source shall not be considered an absolute requirement. %%%%%%%%%%%%% %%% SECTION 3: Membership %%%%%%%%%%%%% \section{Article III --- Membership} Membership in this organization will not be restricted on the basis of race, color, religion, ethnicity, national origin, physical or mental disability, sexual orientation, veteran status, gender identity, gender expression, sex, or age. \\ \\ Membership is open to all currently enrolled GMU students in good academic standing with the university with a minimum cumulative GPA of at least 2.0 who support the advancement of the organization's principles. \\ \\ SRCT members will be classified as either \textbf{contributors} or \textbf{developers}. In this document, the term ``general membership'' shall refer to the combined body of contributors and developers. \subsection{Contributors} Contributors are individuals interested in joining the SRCT community. All new members of SRCT are initially considered contributors. These members may not participate in official votes, nor will they have access to SRCT project management positions. They may contribute to SRCT projects under the guidance and supervision of a project manager. \subsection{Project Manager Positions} Project Managers are the lead figures in individual SRCT projects. Project managers have the final determination of what elements or decisions enter the production phase of a project, with the exception of the Systems Administrator having veto authority if the change presents a clear and present security risk or management inconvenience, or a veto by simple majority by the executive board if it impacts the larger perception of SRCT or the university. In the event a project manager for a project does not exist and there is no distinct interest in someone taking on the position, the systems administrator will approve production changes at his/her own discretion. Project Managers will be elected at the discretion of the President, Vice President, and Systems Administrator in a simple majority. To remove a project manager is also done at the discretion of the President, Vice President and Systems Administrator in a simple majority. Physical attendance should not be mandatory for participation in this vote. \subsection{Becoming a Developer} To attain developer status, a contributor must demonstrate leadership skills, commitment to SRCT principles, and technical ability. To become a developer, a contributor (hereafter referred to as ``prospective developer'') should notify the Executive Board of their desire to become a developer and present a justification for gaining developer status. This justification should include a brief history of the prospective developer's contributions to the organization. Alternatively, a developer may nominate a contributor to the Board and provide a similar rationale. The Board will review the rationale and vote on whether to admit the prospective developer. If the Board votes against admitting the developer, then the developer body (including the members of the Executive Board) shall be provided with the prospective developer's rationale and will have their own chance to vote, conducted according to the rules of an official vote. If the developers vote to admit the prospective developer, they shall be admitted without prejudice. If the developers vote to not admit the prospective developer, then the prospective developer shall not be given developer status, but may re-apply in the future. No prospective developer may be voted on more than twice in one semester. \paragraph{Developer Selection Criteria} To be accepted as a developer, an individual must meet two of the following three criteria, with emphasis on the first two. \begin{itemize} \item Active contributions to SRCT software projects. \item Active leadership participation in SRCT community events. \item Active social participation in the SRCT community, including meeting or event attendance. \end{itemize} \subsection{Developers} Developers are individuals invested in the SRCT community. These members have full voting rights and may request project management positions. A project management position entails access to SRCT infrastructure as required by their project, and as overseen by the System Administrator. Additionally, project management entails the responsibility to maintain project documentation and oversee project development. Developers may also contribute to SRCT projects under the guidance and supervision of the project manager. To attain developer status, a contributor must demonstrate leadership skills, commitment to SRCT principles, and technical ability. Prospective developers will be selected based on these qualifications by official vote. Any prospective developer will not be voted on more than twice per semester. Any developer who leaves the university, whether by graduating or otherwise, loses their developer status. Developers who graduate automatically become alumni members. Developers who leave the university without graduating do not automatically gain alumni status, but may request alumni status from the Executive Board, who will decide the matter by a majority vote. Developers who are expelled lose their developer status and may not request alumni status. \\ \\ The following categories, \textbf{alumni members} and \textbf{honorary members}, are special categories of membership. The purpose of these categories is to allow non-GMU people to contribute to SRCT. Members of these categories shall be listed as members, but will not be counted in membership totals, and will not count as ``Members'' when this document refers to such. \subsection{Alumni Members} Alumni members are former developers or contributors who graduated from George Mason in good standing with SRCT. They may contribute to projects and offer advice, but they may not vote, hold leadership positions, or control SRCT resources. \subsection{Honorary Members} Honorary members are people who have been recognized for providing significant service, expertise, or other contributions to SRCT. They may be nominated by any contributor or developer and must be approved by a majority vote of the Executive Board. They may contribute to projects and offer advice, but may not vote, hold leadership positions, or control SRCT resources. \subsection{Revocation of Membership} In extraordinary circumstances, if a motion is brought and seconded at a meeting for revocation of a developer's status, the SRCT general membership will be notified by email of the motion not less than five days before the following meeting. If a quorum of developers is present, an official vote will be held by secret ballot, requiring a $\frac{3}{4}$ supermajority of present developers. Although an official vote, all present contributors will be allowed to present arguments for or against revocation of developer status prior to the vote. \\ \\ Developer status will be automatically removed if suspended or expelled by the university. %%%%%%%%%%%%% %%% SECTION 4: Officers %%%%%%%%%%%%% \section{Article IV --- Officers} Officers' terms are for two semesters; there are no term limits. All officers will attend any training required by OSI. The \textbf{Executive Board} is defined as the collection of all five officer positions. \subsection{President} The President of SRCT presides over all meetings; serves as spokesperson for SRCT; acts as its main liaison to the Advisor, and OSI; oversees the transition to next semester's officers, and ensures SRCT fulfills its constitutional obligations. Upon election, the president assumes a position on the Infrastructure Management Team. \subsection{Vice President} The Vice President assists the President of SRCT to the extent the President requests, and assumes the responsibilities of the President in the President's absence, resignation, or removal. The Vice President oversees all voting. \subsection{Treasurer} The Treasurer keeps accurate records of any expenditures and accounting as outlined by the Office of Student Involvement's ``Fiscal Management Policies and Forms.'' \subsection{Secretary} The Secretary takes minutes at each meeting and publishes them to SRCT's website, keeps record of the membership status of SRCT members, and maintains all other necessary records and files. \subsection{System Administrator} The System Administrator is technical representative for the membership body, fields all questions related to technical issues from project managers, and directly supervises all project managers. Upon election, the System Administrator assumes a position on the Infrastructure Management Team. \subsection{Removal of Officers} Two SRCT developers may present a motion to remove an officer. The general membership will be notified by email, and developers will have no fewer than five days to review the motion. If a quorum is present at the next SRCT meeting, the motion may be approved by a $\frac{3}{4}$ vote by secret ballot of all present developers. This is considered an official vote. \subsection{Advisor} The primary Advisor shall be a full time member of the faculty or staff at George Mason University. The Advisor shall be selected by agreement of the officers, and it is the responsibility of the officers to find a replacement should the Advisor no longer be suited for the position. The Advisor may offer guidance and support for SRCT, but may not participate in any votes. \subsection{Infrastructure Management Team} The Infrastructure Management Team is the body is placed in charge of all SRCT hardware and software. This board does not fill a seat of the executive board and has no powers vested to that team. The President and System Administrator will have a seat on the board unless impeached or removed by vote of Infrastructure Management Team. The other two members are elected by the Infrastructure Management Team and remain members until resignation or loss of affiliation with George Mason University. Lastly, the operation of the Infrastructure Management Team is governed by the Infrastructure Management Guidelines. %%%%%%%%%%%%% %%% SECTION 5: Elections %%%%%%%%%%%%% \section{Article V --- Elections} \subsection{Standard Elections} Elections will be held during the first meeting of March, with the results to come into effect at the start of the following semester. \\ \\ Voting shall be handled in a secret ballot to be counted by the highest ranking executive not in contest for any officer position, or if all positions are in contention, then by a quorum of all developers not directly involved in elections. \\ \\ In the event of a tie, a second round of voting will be held between the top two candidates following the same procedures of the first round. \\ \\ In the event of a further tie, the Advisor will determine the winner. \subsection{Special Elections} In event of the resignation of an officer, removal of an officer, or any other situation in which there is a vacant executive position, an election will be held to fill that position for the remainder of the term following the procedures above. %%%%%%%%%%%%% %%% SECTION 6: Impeachment or Resignation %%%%%%%%%%%%% \section{Article VI --- Impeachment or Resignation} While an officer is in an elected position, they must fulfill the responsibilities of that position. If an elected officer fails to perform their responsibilities or abuses the privileges of their position, they will be subjected to impeachment and a subsequent removal of office. \subsection{Removal of Officers} Two SRCT developers may present a motion to remove an officer. The general membership will be notified by email, and developers will have no fewer than five days to review the motion. If a quorum is present at the next SRCT meeting, the motion may be approved by a $\frac{3}{4}$ vote by secret ballot of all present developers. This is considered an official vote. \subsection{Officer Resignation} In the event that an elected officer no longer wishes to hold their position, they shall announce their decision at the next SRCT Organizational meeting. If they are not able to attend the meeting, then they are responsible for finding another method to communicate this decision to the other officers. \subsection{Vacant Positions} If an elected position becomes vacant due to an impeachment or resignation, a special election will be held to fill that vacant position as described in Article V.II. %%%%%%%%%%%%% %%% SECTION 7: Meetings %%%%%%%%%%%%% \section{Article VII --- Meetings} SRCT shall meet on a weekly basis. Meetings should be scheduled to accommodate the greatest number of members. All members of the Mason community are welcome to attend meetings. Attendance by SRCT contributors and developers is not mandatory, but highly recommended. Consistent absence may be viewed as grounds for revocation of developer status. \\ \\ The Executive Board has the right to call its own private meetings at its discretion. \\ \\ A quorum shall be defined to include at least two officers, and either a simple majority of developers or seven total developers including at least two officers, whichever is less. On official votes, in the event of a tie, the deciding vote shall be cast by the presiding officer. \\ \\ The President shall preside over all meetings. In the event of the President's absence, the meeting shall be presided over by the highest ranking available officer. \\ \\ The most recent edition of Robert's Rules of Order will guide meeting procedure. \\ \\ Meetings will consist of at least one of two possible discrete sections, an \textbf{organizational} section and a \textbf{development} section. What type of meeting is scheduled for a particular week will be made clear at the time of the meeting's announcement. \subsection{Organizational Meeting} Organizational meetings are to present motions, discuss status of SRCT initiatives and other matters of interest or concern to SRCT, vote on germane resolutions, and other matters permitted by SRCT's officers. All members of the Mason community are welcome to present topics of discussion at meetings. Developers and contributors may vote on non-official resolutions. \subsection{Development Meeting} Development meetings are not subject to the rigorous standards outlined above. They are entirely optional meetings. Development meetings will be used to provide developers and contributors with an opportunity to meet in person and work together on projects in a relaxed atmosphere. There are no time or attendance limits, requirements, or expectations placed on development meetings. %%%%%%%%%%%%% %%% SECTION 8.1: Finance %%%%%%%%%%%%% \section{Article VIII.I --- Finance} No dues shall ever be required as part of SRCT membership. \\ \\ This clause shall not be construed to restrict other fundraising mechanisms. %%%%%%%%%%%%% %%% SECTION 8.2: Amendments %%%%%%%%%%%%% \section{Article VIII.II --- Amendments} Two developers may jointly propose an explicitly defined constitutional amendment at a meeting. The general membership will be emailed a copy of the language of the amendment and have no fewer than five days to review the proposed amendment. At the next SRCT meeting, if a quorum is present, the amendment may be approved by a $\frac{3}{4}$ vote by secret ballot of all present developers. This is considered an official vote. \\ \\ The Office of Student Involvement must review all amendments in the same matter as a completely new constitution. \\ \\ Changes which do not affect the meaning of the text, such as updated formatting and links, may be made at the discretion of the board. \\ \\ While contributors may not directly propose amendments, they may convince developers to sponsor an amendment on their behalf. Developers should only sponsor an amendment if they agree with the changes to be made. %%%%%%%%%%%%% %%% SECTION 9: Ratification %%%%%%%%%%%%% \section{Article IX --- Ratification} This constitution shall become effective upon approval by a $\frac{3}{4}$ vote of the developers, and a Student Involvement staff member. This is considered an official vote. \\ \\ Constitution Ratified on: March 28, 2017 \end{document}