Introduce yourself via a utknetid.md file (please use all lowercase), and submit via pull request.
Please provide at least one sentence on your background and one sentence on your interests. For example,
I am Audris Mockus and I am a professor at the EECS department. I have worked at ATT Bell Labs and and other industry labs for over 20 years. I like coding and data analysis and would like to share my passion with you teaching this course.
Please make sure there is a sentence I am Firstname Lastname' in your utknetid.md. Your utknetid is
the part of your email address that preceeds "@vols.utk.edu".
Follow the remaining instructions in initial tasks
As you'll see in the Team Policy Statement below, you will have assigned roles in your teams (coordinator, recorder, checker, etc.) that rotate among the members. You may be inclined to ignore these role assignments and just do the work in any way that comes to mind, or maybe one team member will actually do the coordinating all semester no matter who is supposed to be doing it for a given assignment. That's a mistake. I strongly advise you to take the roles seriously --- your work will go more smoothly and turn out better if you do. Also, the roles each involve different skills, all of which you'll need to function effectively as professionals. Now is the time to start picking up those skills and you can't do it if you never take on the roles.
Some teams like to divide and conquer, parceling out different parts of the assignment, completing them individually, and stapling the different parts together and handing them in (perhaps after first recopying them in a single handwriting to make it look more like a unified effort). Don't do it! On tests and/or when you report on your work, you will be examined individually on every aspect of the assignment, and your grade will depend in part on how well you understand both the part that you mainly did and all the other parts. Before you hand anything in, go over it in detail and make sure you're ready for that examination.
A common mistake is for teams to sit around a table and solve all problems together. What usually happens is that someone on the team is faster than the others, and that one will begin every problem solution. If you happen to be in the slower category, you may have to figure out how to approach such problems for the first time on the tests, which is not when you want to do it. A better approach is for every team member to outline the solutions individually, and then get together to work out the details.
#Team Policies Your team will have a number of responsibilities as it completes problem and project assignments.
-
Designate a coordinator, recorder and checker for each assignment. Add a monitor for 4-person teams. Rotate these roles for every assignment. Designate one member to be ready to present the work in front of the class.
-
Agree on a common meeting time and what each member should have done before the meeting (readings, taking the first cut at some or all of the assigned work, etc.) There will be at least two classes per project reserved exclusively for this purpose, but don't expect that to be sufficient time for your joint work. Therefore,
-
Do the required individual preparation. That means editing and pushing the code, charts, presentations, or text to the teams' repository before the meeting.
-
Coordinator checks with other team members before the meeting to remind them of when and where they will meet and what they are supposed to do.
-
Meet and work. Coordinator keeps everyone on task and makes sure everyone is involved, recorder prepares the final solution and creates the pull request to submit it, monitor checks to makes sure everyone understands both the solution and the strategy used to get it, and checker double-checks it before it is handed in. Agree on next the meeting time and roles for next assignment. For teams of three, the same person should cover the monitor and checker roles.
-
Review returned assignments, read any comments made in the pull request. Correct if corrections are needed.
-
Consult with your instructor if a conflict arises that can't be worked through by the team.
-
Dealing with non-cooperative team members. If a team member refuses to cooperate on an assignment, his/ her name should not be included on the completed work. If the problem persists, the team should meet with the instructor so that the problem can be resolved, if possible. If the problem still continues, the cooperating team members may notify the uncooperative member in writing that he/she is in danger of being fired, sending a copy of the memo to the instructor. If there is no subsequent improvemnt, they should notify the individual in writing (copy to the instructor) that he/she is no longer with the team. The fired student should meet with his/her instructor to discuss options. Similarly, students who are consistently doing all the work for their team may issue a warning memo that they will quit unless they start getting cooperation, and a second memo quitting the team if the cooperation is not forthcoming. Students who get fired or quit must either find another team willing to add them as a member or get zeroes for the remaining assignments. As you will find out, group work isn't always easy --- team members sometimes cannot prepare for or attend group sessions because of other responsibilities, and conflicts often result from differing skill levels and work ethics. When teams work and communicate well, however, the benefits more than compensate for the difficulties. One way to improve the chances that a team will work well is to agree beforehand on what everyone on the team expects from everyone else. Reaching this understanding is the goal of the assignment on the Team Expectations Agreement handout.
Oakley, B., R.M. Felder, R. Brent, and I. Elhajj, "Turning Student Groups into Effective Teams," The Journal of Student Centered Learning, Vol. 2, No. 1, 2004, pp. 9-34, www.ncsu.edu/felder-public/ Papers/Oakley-paper(JSCL).pdf
###Read at least the appendix on coping with Hichikers and Couch Potatoes on teams.