VALS semester of code

Semester of Code 

Timelines and workfow

The Timeline

You may have noticed the the image shown at the bottom right of the front page of the site. In fact it is almost identical to how the Google Summer of code works, if you are familiar with it.

timeline This image shows the current period of the Semester of code. There are 3 distinct periods during the Semester of code. (There are some smaller periods interspersed also.)

  1. Organisation/Institution application period (or organisation signup period)
  2. Student applications period (or student signup period)
  3. Coding period

Most of the activity in the system takes place during these 3 periods.

Organisation/Institution application period

During this period we initially invite organisations and institutions to register into the system.

For organisations we initially make contact with someone from a particular organisation who wants to be involved, be a mentor for and submit possible project ideas for students. Once the contact is established a generic 'organisations' code is privately sent to that individual by email. That person will use the code to register into the system as the lead organisation administrator for that particular organisation. Once this is setup, the newly created organisation profile will have its own codes for inviting other users. They are then encouraged from that point on to invite other members of their organisation to signup using the code key which relates to their organisation. As more mentors are added to an organisation, the hope is that more project ideas are added for prospective students.

The process is almost identical for institutions. Partner universities and institutions are encouraged to nominate someone to act as the initial lead institute administrator for that particular university. That person uses a generic 'institution' code to setup their institutions profile into the system. Again, that person can invite other members of staff from their institution using a institution specific generated code for colleague admins or student supervisors. Supervisors are encouraged to browse the list of project ideas submitted by organisations and mark out any that they feel comfortable they could supervise students with. Later on, students will choose a supervisor they like to work with seeing the list of supervisors liking this project. Furthermore, supervisors can give comments on projects as suggestions to the mentors to shift the focus or comment on how they see this project fit into the curriculum of the students. People can give comments on eachothers comments perhaps to ask questions, clarify things and so on. Students generally do not enter the system yet, but if added during this period, their options are very limited until the next period opens.

Student applications period

During this period students become active in the system, essentially meaning that they can browse the project ideas, mark their favourites and start to write proposals for one or more of the project ideas. Normally they would first create a project proposal and save it in draft mode. Together with their supervisor they can refine it and when ready, also choose to make it accessible to the project mentor by saving it as 'open draft' or as 'final'.

The mentor can now provide feedback on the proposal. He/she can decide to mark a particular proposal as their 'interim' choice, meaning they can change their mind if they receive a superior proposal for that project idea. Alternatively they can decide to choose this particular proposal and set it as their final choice. This means that the project is now being 'offered' to that student.

The student now has to login to the system and choose whether to accept this project offer. If they decide to accept it, that project is set as their final project for the Semester of Code and it is the one they will start to work on.

Projects for which the offers is rejected by the student (he/she had more than one offer and chose another for example) are made available again in the system. This means that the mentor can now offer the project to another student instead.

For all of these state changes in projects, the involved persons are acknowledged by email.

Coding period

The student works on the project.



In essence the workflow can be boiled down to the following sequence

  1. Organisation and institution admins register in the system and optionally invite others to participate
  2. Mentors and supervisors register in the system
  3. Mentors create and add projects to the system
  4. Supervisors mark which project ideas they would ideally like to supervise students with (optional)
  5. Supervisors create 'groups' in which to add students to (optionally there is just one group for everyone)
  6. Students register into the system
  7. Students browse the list of projects and decide which one/s they would like to tackle as their project and marks them as favourite.
  8. Students start to write proposals and save them in 'draft' mode. This means only the student and his/her supervisor can see it.
  9. When the student & supervisor are happy with the proposal they can either choose step 10 or 11 (or a series of both).
  10. Student saves the proposal as 'open draft', which means that now the project mentor can also see it, while still allowing the student to make changes to it.
  11. Student saves the proposal as 'final' which means it can no longer be edited and is set to the final version. Note: some mentors may ask that the proposal is set to 'final' before making a project offer to a student.
  12. The mentor reviews the list of proposals for a particular project idea. Optionally they can either...

    • accept one proposal as their interim choice. This means that although it is their current preferred proposal for this project idea, they may still change their mind later.
    • accept one proposal as their final choice. This means that the mentor has decided to offer the project to the student who created this particular proposal.
    • reject a particular proposal, but also giving some sort of feedback on why.
  13. The student now has to decide whether to accept the offer. If the student just has one offer, then he/she would accept that offer, meaning that this project idea is now taken and is being completed by him/her. Any other proposals for this particular project idea made by other students have been unsuccessful and so are now marked as 'archived' in the system.
  14. If the student has multiple project offers, the situation is a little more complex. When the student chooses between more than one offer, any other offer he/she had from another mentor becomes void, meaning that its 'final' state is reset, allowing the mentor to offer the project to another student.
  15. The student, mentor and the students supervisor can all now optionally work on agreeing what work will take place, milestones etc, using an agreement form. This is optional, as this may have been done already in the proposal, or is not required by the parties involved. Signing an agreement form makes (additional) expectations from both sides clear and also clearly marks the beginning of the work.
  16. The student now enters the coding phase and starts the project work
  17. Towards the end of the coding period the student ensures that the work done is availbale to the supervisor and mentor for review.
  18. After the coding period, the supervisor and mentor discuss the work done by the student.
  19. There is an informal review with student, mentor and supervisor (optional).
  20. The student, supervisor and mentor sign off the students work by confirming that they are satisfied.
  21. The student now gains merit or credits, on whatever part of their studies was agreed to with their supervisor.


All dates and times on the website are expressed in Coordinated Universal Time (UTC).