Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
  1. Your proposal is your contract
  2. Don't get lost
    1. Blog weekly to report progress
    2. Push on a regular schedule every few days
    3. Write design notes for review
    4. Get weekly review on code and design
    5. Identify blockers immediately
  3. Bond
    1. Get your contribution through to RTI
    2. Keep working on bite-sized bugs
    3. With feedback from your mentor, identify background reading assignments for the bonding period
    4. Spend time on #illumos

We don't want students to disappear and end up at risk of failure. We're therefore setting up a number of protocols to help us keep track of progress on a day-to-day basis without too much overhead. There are a number of further things you can do to help yourself out. Get on the #illumos IRC channel and get to know the developers who are active there. Our developer community is an essential part of the larger mentor community supporting your project, so please consider the mailing list and IRC first-instance resource for general requests.

Proposals should be considered a contract: they can be renegotiated, but you can't fail to deliver. If you need to make changes, indicate that promptly and make sure that the changes have been notified to and approved by your primary mentor and the org admins (Bayard and Albert).

An illumos-gsoc organization has been created on GitHub, and WIP repos are being created for each project. Updates to the WIP are your basic keepalive: you should be pushing every day or two whenever you are coding. If you are going to miss a push or have one, please send notification to your primary mentor and the org admins, preferably in advance, explaining the circumstances.

The repos should also include documentation for your project, such as design notes. Because they are WIPs, the repos are private. Reviews should be done using webrevs. You will be given accounts on dev1.illumos.org to allow you to publish code for review using webrevs.

Every week you should provide a blog post describing progress and a webrev of any code done that week, sending URLs to developer@. The first post, which should be made during the bonding period, should be the project schedule and deliverables so that the developer community is aware of what you will be doing.

You cannot miss these weekly progress reports except by prior arrangement or in case of legitimate emergency.

If there are any slips against the project schedule, you should identify them in these posts the week they happen.

If you encounter blockers, mail the developer list and ask on #illumos to request assistance ASAP. First-instance support for blockers should be from the developer community and not tied to any individual unless there is a clear reason for this and preferably prior agreement.

If you haven't already, create accounts for yourself on github and the illumos.org redmine issue tracker.