Team Standards/Bylaws

1. Roles

1.1. Leader - Erik Wilson

Erik Wilson is our leader. He is in charge by default and his final decisions will be overturned only when all three of the other members vote against him (simple majority).

1.2. Communicator - Ben Atkin

It is Ben's duty to ensure that our group is responsive. If our teacher or one of our sponsors emails us, he will reply within 24 hours.

1.3. Recorder - Nauman Qureshi

Nauman is in charge of keeping our team notebook and meeting minutes. Some days minutes will be short, other days they will be longer, and if at a meeting nothing new is discussed, minutes will not be needed. This will keep the task of keeping minutes from getting in the way of other, more important tasks.

1.4. Facilitator - Thaddeus Boyd

When there is a dispute, Thad will attempt to resolve it. See Section 2.6.

2. Meetings

2.1. Weekly Meetings

Hour-long meetings will be held three times a week: Monday, starting at 5:15PM, and Wednesday and Friday, starting at 10:30AM. Our schedules are open after the Monday meeting, giving us time to work on our project.

2.2. Standard Agenda

The standard agenda for our meetings is as follows:

Old business

Individual progress reports

New business

2.3. Decision Strategy

The Simple Majority method will be used.

2.4. Minutes

Minutes will be distributed across the team the day after the meeting takes place, via plain text email.

2.5. Attendance Rules

If a team member misses a meeting without notice, it is his obligation to buy pizza for the next meeting.

2.6. Conflict Resolution Strategy

When there is a conflict, it is the duty of the facilitator to resolve it. If that doesn't work, we will contact a neutral party (Eck Doerry).

3. Document Standards

3.1. Word Processor Version

Documents will be submitted in Microsoft Word 2000 file format. Documents will also be available, from our website, in OpenOffice and .pdf file formats.

3.2. Coordination

Erik and Nauman will coordinate efforts for producing team documents in a clear and consistent format.

3.3. Version Control

A CVS repository will be set up and a guide to using its basic features (including rolling back to an older version) will be sent to all team members. This task will be completed by Ben.

3.4. Format

Documents will be sent using a Memo format, with the date, sender, recipient, and title information at the top of the page, followed by the content and/or a description of the attachments. Because it has been shown that serifs make the printed page easier to read, we will be using 12 pt. Times New Roman for all of the body text. Courier New will be used for code excerpts. Arial will be used for all of the headings. Page numbers will appear in the bottom-center part of the page. Date formatting will be YYYY-MM-DD.

3.5. Review Process

Individual components of a document shall be delivered two days before the deadline. The review and final modifications will be done the day before the document is due. Progress will also be monitored during our weekly meetings.

4. Self Evaluation Method

4.1. When to Evaluate

Self-evaluations are held every Friday.

4.2. How to Evaluate

On our Friday meetings, we will rate the past week's performance as horrible, OK, or good. We will discuss what went wrong and how to improve our work habits for the following week.

5. Standards for Behavior/Cooperation

5.1. Design Changes

We will use our usual decision process for design changes. This means that we will discuss it as peers, and try to reach a consensus. If we can't reach a consensus, we will try to delay the decision. Once this route has been exhausted, Erik will make the decision. If every other member of the team disagrees with him, by rule of simple majority, he will be overruled.

We encourage all team members to pursue any good ideas they have, try to code it themselves, and present it to the rest of the team. This is their best shot at getting their idea into the final product.

5.2. Standards for Behavior/Cooperation

We, as a team, want all members to contribute. This means that all members should pay attention to the topic. What this does not mean, is that we can't be social during meetings. Oftentimes, out of general conversation about computer science topics, we will get insightful comments directly related to our project.

What is not tolerated, however, is ignoring another member of a team, or talking over them. If this happens to any member, they need to speak up. If this isn't dealt with satisfactorily, we have a conflict, and the conflict resolution rules apply.

As for lateness, we have nothing in our rules about it, unless a meeting is actually missed, but it will affect the peer evaluations, and if it really gets out of hand, could very well be reported to our teacher.

Page 3

2004-01-28T19:49:39