Skip to content

Instantly share code, notes, and snippets.

@mdparker
Created August 31, 2022 07:15
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mdparker/47d77649d2a09c31f529160b4176512f to your computer and use it in GitHub Desktop.
Save mdparker/47d77649d2a09c31f529160b4176512f to your computer and use it in GitHub Desktop.

SAOC 2022

Congratulations again on a successful application! Now it's time to get to work. This document describes your next steps in preparing for the event, what is expected of you as the event progresses, and what you can expect from us throughout.

If you have any questions or problems with this document or the event itself (the process and procedures, not your project), or any difficulties with your mentor, at any time from now until the end, please contact me directly at aldacron@gmail.com.

Next steps

You are now project planning period. That means finding a mentor if you don't already have one and putting together your milestone document for the judges.

Finding a mentor

If you do not already have a mentor, then your next step must be to find one. If you know of any people whom you can contact, please do so. If you need to hunt for someone, I suggest you start with a post in the General forum to see if anyone is interested. Additionally, if you need help finding someone, I will see if I can put you in touch with someone both willing and suited for your project.

Finalizing your milestones

Once you do have a mentor, you are ready to get down to the details of planning your project. The milestones you submitted in your application were a draft. Now you need to finalize them. Your final milestones may not look like the draft list. That's perfectly fine.

The milestone document you submit to us at the end of the planning period is a critical component in the evaluation of your progress at the end of each milestone. They should be as clearly defined as you can make them, with enough detail that there is no doubt of your intentions.

Each milestone should have the following format:

  • Milestone 1: A Descriptive Title Goes Here
    • A description of the first task.
    • A description of the second task.
  • Milestone 2: Another Descriptive Title
    • A description of the first task.
    • And so on...

Your task descriptions should not be vague. The judges cannot properly evaluate your progress if your task descriptions do not provide enough detail. You don't need to write a huge amount, but you do need to provide enough information that the judges can have a clear picture of what is involved in completing the task. A very basic example:

DON'T

  • File saving/loading
  • Menu

DO

  • Implement save and load functions for all supported file formats
  • Add 'Save' and 'Open' items with platform-appropriate shortcuts to the 'File' menu and implement save and open handlers for each supported file format

In this case, given that saving and loading files are operations that we all understand, there's no need for additional detail about what the save and load functions should actually do. But consider a milestone like "Implement a sprite renderer". Anyone who's had an interest in game programming will generally understand what goes into a basic sprite renderer, but even then, sprite renderers can have a number of different features. In this case, the tasks involved in implementing the renderer should provide enough detail that a layman would understand what's happening:

  • Milestone 1: Implement Basic Sprite Renderer
    • Implement a function to convert sprite image data to a texture format understood by the underlying graphics APIs.
    • Implement functionality to "blit" a texture onto a 2D quad.
    • Add support for alpha-channel transparency.
    • and so on

Add as many tasks as you need and can reasonably acheive within the milestone period. And when I say be as detailed as possible, I mean in terms of how you describe the task, not in terms of the work the task entails. In otherwords, don't drill down to the lowest level of individual work items for the task description, but try to keep it focused on a higher level of related work items. I the save/load example, I did not add a task for each file type, but instead focused on the higher level save/load functionality. The sprite renderer example might have support for DirectX, OpenGL, Vulkan, etc, but you don't need a separate task for each API to implement a specific feature (e.g., texture loading). As in my example, one task can encompass every API you're working with.

You should develop your finalized milestones with your mentor. We highly recommend that you and your mentor schedule a time to discuss the milestones in person, via either an audio or video medium (the D Language Foundation members frequently use meet.jit.si these days, often only with audio for short meetings, and we're all quite happy with it). Email communication, even with the best of intentions, can suffer from delays that harm productivity, especially when multiple emails in a single conversation are involved. Meeting in person, even if it's only via audio, is a much more productive approach and greatly reduces the odds of suffering from misunderstanding or confusion.

When your milestones are finalized and you have your mentor's approval, you will need to send the document to me no later than September 15th, UTC, in Markdown format. Of course I will accept submsissions that are late, but please remember that your ability to meet the deadlines we set throughout the event will play a part in the final evaluation at the end.

What we expect of you

Your primary objective is to successfully complete your milestones. That does not necessarily mean you need to complete your project. If your project does require more work beyond the bounds of the event, we hope you stick around and see it through. But no one expects you to complete the project by the end of SAOC unless your milestones dictate that you should.

What we do expect is that you put in the work and are able to show it. The milestone document is one way the judges can determine if you have done the work. There are two other components that will assist them.

Weekly forum updates

You will be expected to post weekly updates about your progress in the D General Forum. Each post should be a new thread (please, do not post all updates in a single thread) and should summarize the work you did for the preceding week. Your first post will be expected from September 21, in which you will summarize the first week of Milestone 1. Subsequent posts will be expected on a weekly basis.

These posts often spark discussion, so be prepared to answer questions about the work you're doing. You may also receive helpful advice and tips.

And do not forget that the forums can be an excellent source of help when you are stuck.

Milestone reports

Milestones begin on the 15th of each month and end on the 14th. At the end of each milestone, you will need to submit a milestone report no later than the 22nd of each month. For example, the first milestone ends on October 14th, so you will need to send your Milestone 1 Report to me by October 22nd.

Each milestone report should summarize the work you did to complete the tasks for the finsihed milestone. What steps did you take? Did you encounter any problems? If so, how did you overcome them? Were you unable to complete any of the tasks? If so, why not? What did/will you do instead? Do you need to adjust the tasks for the next milestone? If so, how?

Your programming work needs to be in a source code repository accessible to the judges, and you should include links to any commits you made during the milestone. Some of your work will not be visible. For example, one of your milestone tasks may be to research a protocol or an algorithm. In that case, provide links to the sources you used for your research and a summary of what you learned.

You will also need to include links to your weekly forum updates. The judges aren't going to search the forums looking for your posts. If you want the judges to know for certain that you are keeping up with them as expected, then you need to include the links to them in your milestone report.

In short, your milestone reports should include enough information for the judges to feel confident enough that you are doing the work and not wasting time. If you submit a report and I have to ask you for more detail, you're doing it wrong.

Do not get lazy with these reports. I can tell you that the one of the reasons we awarded two participans a final $1000 payment in 2020, and that two participants got the full final reward in 2020, is because they wrote milestone reports that left no doubt about how they spent their time. Each report was only a few paragraphs long, but they were concise with enough detail to leave no doubt.

The final milestone report should include a summary not just of Milestone 4, but of the entire event. I will provide more detail to you on that topic when Milestone 4 is nearing its end.

Remember, milestone reports are due on October 22nd, November 22nd, December 22nd, and January 22nd.

Before you send your reports to me, send them to your mentor. This step is important. If we find out that your mentor never saw your milestone reports before you sent them to me, it will have a negative impact on your final evaluation at the end of the event. So when writing a report, give yourself enough time in that seven-day window for your mentor to review it.

Performance evaluations

While you are preparing your milestone reports, your mentor will be preparing an evaluation of your performance. Your report is about the product of your progress. The evaluation is about the method. Are you overachieving, underachiveing, or steadily chipping away? Are you responding to your mentor's communications or ignoring them? Are you sticking to your tasks or bouncing around aimlessly?

By and large, performance evaluations are overwhelmingly positive. You mentor wants you to succeed as much as, or even more than, we do. If all is normal, then the performance evaluations will have very little influence on your evaluation for any given milestone. The most weight is given to your reports, with your milestone lists right behind.

What we look for in the performance evaluations are comments that go beyond what's normal. For example, when the mentor is impressed by your work. This is the sort of thing that will influence your final evaluation. We also look for negative comments, such as when your mentor says you haven't been in touch in two weeks, or you seem to have lost motivation. In such circumstances, I will reach out to you to get your side of the story before the judges weigh in.

Passing/Failing milestones

Taken together, your milestone lists, milestone reports, and performance evaluations should provide the judges with enough information to determine if you passed or failed a milestone. And I want to be clear about this: we want you to succeed. The judges are extremely reluctant to fail anyone. You generally have to bomb a milestone completely to fail it.

That said, one or two people fail out of the event every year. Usually, it starts with a milestone that is less productive than anticipated. The participant fails to complete all of the tasks, but doesn't have a good reason for it. By definition, the milestone is incomplete and the judges are free to fail the participant. But like I said, they are reluctant to do so. They are usually willing to give the participant a second chance. Instead of failure, they will provide the participant with a reduced payment for the milestone (e.g., $500 instead of $1000) and the participant will be allowed to continue. This is done with the understanding that it is highly unlikely the particpant will then be selected for the final payment and the DConf trip at the end of the event (though anything is possible). If the participant then fails to meet the next milestone, then that's the end for that participant.

I tell you this because it's how the judges have behaved in each of our previous SAOC events. I cannot promise that they will continue to do so. Whether or not they give any particpant a second chance is entirely at their discretion.

If you do fail a milestone, the next milestone will be well underway by the time you learn of it. Given that your reports are due on the 22nd, the judges will have until the 29th to reach a decision. I will let you know as soon as I hear from them if you have passed or failed. In the meantime, you should keep working on the new milestone under the assumption that you have passed.

Even when you fail, we still generally won't send you away empty handed. To date, no one who has failed has not been paid at least $500 for their failed milestone. Again, I tell you this because that's the way we have operated the event to date, but we are under no obligation to pay you anything for a failed milestone.

For the final evaluation, the judges will review all of your milestone reports and performance evaluations once more, take a good long look at what you've got to show for the event, and give your overall summary a read. To select one participant for the final payment, they'll weigh all of that against the other participants, accounting if need be for missed deadlines, partially failed milestones, overachievements, creative solutions to challenges faced, and other minor details. There are no specific criteria I can give you. The final evaluation heavily depends on the quality of the documents submitted and the facts the judges are able to discern about each participant's performance. This is why your milestone reports are vital, as they are the judges' primary source of information about your work.

Working with your mentor

During the project planning stage, you should talk with your mentor to determine how you are going to work together going forward. We strongly recommend that you have regular meetings over an audio or video medium. Once a week is ideal if you are both able to arrange it. This is the most efficient way for you to update your mentor on your progress, and for your mentor to provide suggestions about potential directions in which to take your work, or about potential adjustments to your milestone list. Regular discussions like this will enable the mentor to have a more accurate picture of your performance, which is important when it comes time for your mentor's evaluation of said performance.

Your mentor is there to help you. Take advantage of that. You are working on a limited timeframe for each milestone. Don't waste time trying to solve a problem that has you stumped. When you encounter a difficult problem or challenge that is consuming too much of your time, reach out to your mentor for guidance. Don't wait for your regular meeting. Fire off an email and request an off schedule meeting if you need it. If they don't have a direct answer, they may at least be able to point you in the right direction.

If you find your mentor is frequently unavailable, is not providing guidance, or is just generally not peforming the duties of a mentor, do not heistate to let me know about it. I will have a discussion with the mentor and then the judges will determine the best course forward.

What you can expect of us

The judges are here to evaluate your progress. My job is to make sure you have everything you need and that the process goes as smoothly as possible for you. If you find I'm failing to live up to my end, please let me know!

Communication

The judges will never be in direct communication with you about the event. All SAOC-related communication goes through me. And I will not be contacting you unless I have a need to. I will send you a reminder as the end of each milestone nears, I will occasionally email you about payments (e.g., "did you get your money for the last milestone yet?"), or about questions I or the judges may have. We aren't going to get involved at all in the work you are doing on your project. That's between you and your mentor.

But as I said at the opening, you can feel free to contact me anytime at aldacron@gmail.com.

Payments

Given that your pass/fail status is determined by the 29th of a month, your payment will be sent out in the following month when the D Language Foundation sends out its monthly payments (bounties, contract payments, SAOC payments, reimbursements, etc.). Andrei Alexandrescu handles this. He has typically sent payments out by the 10th of each month, but that isn't always the case. The date he sends payments out is dictated by his schedule.

So your first $1000 milestone payment will ideally arrive by November 10th, with the second and third coming by December 10th and January 10th, respectively. The final payment to one participant should arrive by February 10th. If you are due a payment in one of the given months and do not receive it by the 10th, please let me know.

Conclusion

I hope this document provides everything you need to know about the event. Please let me know if anything is unclear or if I've missed something obvious.

The judges, your mentor, and I are all here to help you, and we all want you to succeed. Symmetry Investments and the D Language Foundation want to pay you at least $3000 for three successful milestones. That's the best case for everyone. None of us are interested in seeing you fail. Your success will be beneficial to the D community, and that's why we're all here.

Before I go, I have one piece of advice: don't think of SAOC as a competition between participants. It's true that only one of you is intended to receive both a final $1000 payment and a trip to a future DConf, but don't think of those as prizes. Think of them as rewards for standing out. The past two editions have shown that Symmetry is fine rewarding more than one person at the end for a job well done, either with one or both of the final rewards, if performance warrants it.

Ultimately, your success or failure is in your hands. Complete your milestones. Meet your deadlines. Do everything we've asked you to with the rigor we've asked you to. That will guarantee you pass your milestones, and you might possibly find yourself with an extra reward at the end.

Good luck, and happy coding!


Mike Parker

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment