Tips and Guidelines for Org Admins

Please read this document carefully. There is a lot of important information below for new and veteran Org Admins.

If you have questions or suggestions for things to add, please contact us.

Organization Profile

  • Ensure that your Organization profile is complete and correct. This is the first thing people will see when trying to learn about your organization.
  • Your description should be clear and concise. Be sure to check for spelling and grammatical errors.
  • Use the "Common Task Information" field to include information you wish to appear on all tasks. For example: Information on configuring a participant's environment, or documentation or help links.

Mentors

  • Invites - Mentors must be invited by an Org Admin to be a Mentor for GCI. Be sure you have the correct google account of the Mentor you are trying to invite - the Mentor must sign up using that same email account.
  • Younger Mentors - Mentors can be as young as 13 years of age as long as their parent completes a Parental Consent form. Invite them as you would any other Mentor, and Google will send a request for Parental Consent. Once the form is completed by their parents and returned to Google, they may then be assigned to tasks like any other Mentor. Note: Organization Administrators must be 18 years or older.

Tasks

Creating Tasks

  • When designing your tasks, keep in mind the time and difficulty involved regardless of what kind of task it is -- do your best to make the tasks roughly equivalent. Yes, this is pretty much impossible, but try to keep things as in line as you can.
  • It is okay to mark tasks with difficulty level (easy, medium, hard) so students can find the easier tasks (or maybe the harder tasks) they wish to select.
  • Most tasks should take students 3-6 hours to complete depending on their familiarity with the coding language, etc. It may be necessary to split or merge tasks to adjust the complexity level.
  • All Mentors can create tasks, only Org Admins can publish them.
  • Make sure that your task titles are clear and understandable to a 13-17 year old. Avoid prefixes or tags in the title.
  • Do not create any tasks that require students to supply personal information. For example, their country, pictures of the student, hobbies, etc. This is personal information and can not be asked or required of students in any manner.
  • Tasks should have a specific tangible output. Code, graphics, documentation, tests, test verification, etc.
  • It is not a "task" to require someone to make an account, sign up for a mailing list, or follow you on social media. Some of those things are overhead, some of the others are blatant marketing and don't benefit the student. We understand that sometimes this kind of trivial task is used as a beginner / hook task, but you'll need to find other things that are not trivial and don’t violate privacy concerns.

Beginner Tasks

Beginner tasks are intended to help students get their feet wet and get introduced to the program. They often include things like setting up the development environment on their computer, or some other way for students to get a feel for what your organization does.

  • Have at least 5 different beginner tasks. This is very important at the beginning of the contest. They do not need to be across all 5 categories.
  • Students may only complete 2 beginner tasks each. After that, beginner tasks will no longer be visible to them.
  • Don’t make the majority of your tasks beginner. If you only have 10 non-beginner tasks it may look like you don’t have anything left for them to choose from. Students want to see new tasks and push themselves.
  • Be prepared for students to complete many beginner tasks. They are popular because they are easy for a student to wrap their head around and say “yes, I can do that”! Students often go on to more difficult tasks once they feel comfortable with how your org and open source works.
  • We encourage you to have many instances of your beginner tasks (most orgs tend to have 20-50 instances available of each beginner task). You can always add more instances as the program goes on.
  • Beginner tasks are something you will want most or all of your Mentors to be able to evaluate. You can expect these to be completed many times and if everyone can review them it will help keep your org’s workload balanced.

Task Instances

Tasks may have multiple instances. This allows you to easily create tasks that can be completed multiple times (by different students.)

  • For example, if you set the number of instances to 15, the task can be claimed up to 15 times and up to 15 students can work on their instance of the task at once.
  • When an instance is completed, it reduces the pool of instances available to be claimed by 1.
  • If a student “abandons” an instance, it then becomes available for another student to work on.
  • You can always increase the number of instances of a task (up to 100.)
  • You cannot decrease the number of instances below the number currently claimed or completed.

Number of Tasks

  • We strongly encourage you to have a minimum of 100 task instances across at least 50 unique tasks available for students to choose from at the start of the contest in all 5 categories including many beginner tasks.
  • Keep an absolute minimum of 25 unique tasks available at all times for students to choose from during the contest. We strongly encourage you to have at least 50 listed at all times, particularly during the first half of the contest.
  • Do not have more than 400 tasks published at once. We want students to be able to see a variety of tasks from orgs, and not be overwhelmed by one org.
  • Be prepared to add new tasks throughout the contest. We suggest using a shared document or private wiki to track ideas.
  • Be sure to create enough tasks for the contest. As a reference point, the mean for task instances completed by orgs in 2018 was 570.
  • Always have additional unpublished tasks in your queue that you can upload as needed throughout the contest. Having additional tasks ready to quickly publish will mean less work for you during the busiest part of the contest.

Reviewing Student Work

  • All Mentors and Org Admins can review all tasks for an organization.
  • It is your responsibility to set expectations with your Mentors about who will be responsible for reviewing which tasks. This includes whether or not it is ok for Mentors to review tasks which they are not explicitly assigned.
  • GCI is open to all 13-17 year old students, regardless of their prior coding or open source experience. Their work might reflect this. It is perfectly acceptable to tell a student that their work doesn’t meet the standards your org expects for a task. Please tell the student promptly that their task needs work and be explicit on what you want them to change. They can then go back and try to fix their work, or "abandon" the task and move on to another that better matches their skill set.
  • Keep an eye on the amount of time remaining on a task, and consider adding more time to the task if you send it back to the student for more work or after a round of comments. This was an issue for a couple of orgs in 2018, please add a couple of extra days if the student's need more time. Or you can make your tasks 4 or 5 days instead of the default 3 if you prefer.
  • Comments you leave for a student will be viewable by the student, Org Admins and Mentors from your org, and Google Program Administrators.
  • Comments can be deleted. This does not prevent an email from being sent.
  • Some students may be upset that it took you longer than they expected for you to review their work. We tell students that Mentors have up to 36 hours to review submitted work (but we suggest that you aim for under 24 hours). Students can be impatient and want to claim the next task -- try not to let them stress you out! A big part of the contest for students is learning about distributed development -- working with people that live many time zones apart.
  • Be sure to leave a comment explaining what needs fixing before marking a task as =More Work Needed=.
  • You should not remove a student from a task without letting them know why you are removing them from a task (this should be done rarely).

Winners and Finalists

  • If you encounter a student that did an exceptional job on a certain task then you should take note. At the end of the contest when your org is reviewing the work of the top 20 students you can point to Task X as to why this student should be a Finalist or Runner-up or Grand Prize winner.
  • We encourage you to track activities throughout the contest. Your org may wish to create a shared document that all Mentors and Org Admins can edit to record extraordinary efforts on tasks - by whatever measurement you decide to use.
  • The best participants are not always those who complete the most tasks, or have the best engineering skills -- but are sometimes those who also contribute to the community by interacting with and helping others.
  • We have added the concept of Runners-up, so now there are 6 finalists per org: 2 of those will be named as Grand Prize winners, 2 as Runners-up and 2 as Finalists. All Finalists will receive a Jacket. Runners-up and Grand Prize winners will also receive a backpack. Grand Prize winners receive their prizes during their trip to Google in San Francisco!

General Reminders

  • If you find a bug or have any questions please contact us.
  • Veteran GCI Mentors and Org Admins have a wealth of knowledge around best practices and are always ready to help! You can use the gci-mentors list to reach them. The archives are also full of useful information.