-
Notifications
You must be signed in to change notification settings - Fork 71
Outreach student faq
Your mentors will work with you to identify tasks that are interesting, challenging and educational.
Initially, take a look at Outreach-student-your-first-pr.
To help the mentors identify suitable tasks, they will need to know a little about you, specifically:
- What computer languages you already know.
- What computer language(s) you want to learn.
- How long you have been programming.
- What areas interest you.
- etc.
Speak to your mentors! They will help you to either find a different way of approaching the task, or identify a more suitable task for you.
No! Please ask questions as soon as you have them so your mentors can help you quickly.
As soon as possible. It's important to start trying to attack the problem as early as possible.
Also, aim to work consistently: allocate the required number of hours per week for the Kata Containers outreach work and stick to it.
Do not adopt one of the following approaches:
-
"I'll do the bare minimum for a few weeks, until I've learned rust."
-
"I'll wait until the last week or so before starting to code."
-
"I'll let my team do most of the work."
Why?
-
Your mentors will notice and grade you accordingly!
-
You will not be taking advantage of the unique opportunity you have been given.
Lots of folk want to get involved in Kata Containers but don't get the "one on one" mentoring opportunity you have, so don't waste it! ;)
-
You will be letting yourself down.
The contributions you make will exist in the git history of the project forever. They can also act as part of your résumé / CV, so make them good.
We've all been there 😄 Rust is an exceptionally difficult language to learn, but it's worth it!
The best advice we can give is:
-
Keep learning about it.
Read the official docs, read articles about rust, etc.
-
Keep talking to each other and your mentors about it.
-
Read as much rust code as possible.
-
Start trying to write simple rust programs as early as possible.
Try to get in the habit of writing simple "self contained" [*] test programs. These are good to cement knowledge of particular language features, interesting rust crates, or to explore areas you are struggling with.
[*] - a
main.rsfile. If you want to get elaborate, you could make the program accept some command-line arguments to control the behaviour of your test program. -
Ask your mentors for help.
- They have tips and tricks.
- They may also be able to provide you with sample programs to help you grasp difficult concepts.
- They will find code/doc examples to help you understand areas you are struggling with.
Ultimately, learning rust is no different to learning any other language. Eventually, your brain will absorb it, but it does tend to take longer with rust!
Day 1, if not before! You cannot learn programming purely from books, presentations or videos. You need to do it ;)
Have a go. Try to write a simple program. Make mistakes. If you get stuck, ask for help.
Absolutely not! You do not need to be a rust language expert to make major contributions to the Kata project.
Don't get caught in the trap of thinking you need to know everything. Just start writing a few test programs a
Whether you each work on a small project individually, or form small groups is up to you and your educational establishment. There are benefits and complications with both approaches, some of which are listed below.
-
Can be a great way to learn more quickly.
Think "pair programming".
-
The challenge is shared.
-
Guarantees that you will communicate with one another!
-
Keeps you motivated.
-
Complicates development.
See the sharing a git repo page.
-
Can be awkward if one of you is ill, or on holiday, or doing most of the work.
-
You may need to compromise on your preferred approach and on which parts of the task you work on.
- You have full control:
- You get to make all the decisions.
- You get to write all the code.
- You get all the credit for the task ;)
-
You may not communicate enough with your team.
Even if the rest of the outreach team are working on other issues, you should all communicate regularly, ideally daily.
-
You may get "stuck".
If you don't know what to do next, or you cannot resolve an issue, speak to your mentors who will help you overcome this! 😄
That can usually be accommodated, but it's easier if you make this decision earlier rather than later in the project cycle.
TL;DR: As early as possible! 😄
Should I wait for my code to be perfect before raising a PR? No!
It's never too early to raise a PR. It doesn't even matter if the code doesn't compile!
Simply add the
wip or rfc labels
to let the community know this is early code and we can start to help
you. The sooner you show the community what you're working on, the
sooner we can all help you fix problems, discuss the design, make
suggestions, give battle-hardened advice, provide pointers to existing
library code you could use, etc.
Remember: Nobody is an expert in everything and everybody involved in the project wants to see it succeed, so you will benefit from raising that early PR.
It's difficult, but try not to fall into this trap! Remember that everyone has been through this process themselves. And all those community members know how hard rust is to learn and will be keen to help you avoid some of the pitfalls they faced! You'll also get extra kudos for raising a PR! 😄
It may feel awkward, but you'll end up learning rust a lot faster if you can raise those PRs as early as possible.
If you really don't want to raise a PR (and seriously, you should ;), there is another option:
- Push your
gitbranch to your fork of the Kata code on GitHub. - Go to
https://github.com/${your-github-user}/kata-containers/settings - Click "Collaborators".
- Click the green "Add people" button
- Add your fellow team members and/or mentors.
- The collaborators can then see your branch and make comments and suggestions.
You can't do that, even by mistake! 😄
We run multiple
CI systems,
multiple static analysis systems and require at least two senior
project members to "sign off" / approve / "ack" your code before it
can "land" (be merged into the main branch). So even if your PR does
somehow get through all these checks and breaks Kata, that would
not be your fault: it would be the fault of those who approved
the code.
Talk to your mentor(s) and they will likely suggest that you break the code into smaller parts which can be converted into individual smaller PRs. They will help you do this.
When you raise a PR, members of the community will review it by making comments and asking questions.
Sometimes, you may not understand their comment or you may disagree with their views. This is natural. In these cases:
- Speak to your mentors.
- Respond to the comments on your PR asking for further information or clarification.
Maybe the commenter may have misunderstood your code. Maybe you have misunderstood the task. The crucial point is to keep communicating until you both understand: the commenter understands your PR and you understand the commenters point of view.
Talk to your mentors.
But also, try clicking the failing CI to see if there are log files that you can look at to try to identify the failure. Our CI is very complex and occasionally will fail due to timeout or network issues. It could also fail due to a code problem unrelated to your changes.
Spending months working on a large piece of code "in private" and then raising a PR right at the end of the project isn't a good strategy in general. Since the mentors and the community cannot see the progress you're making, you may find that you need to rework the code significantly, or possibly even rewrite it entirely (although that's unlikely).
There is also the risk that since you've kept what you're working on hidden, that others in the community might be working on the same feature / bug fix. We try to minimise this by ensuring that you have an assigned issue that describes the work before you start writing the code, but there have been a few incidents (at least three) in the past where multiple folk have raise PRs for the same work.
Hence, it is strongly suggested that you raise a PR as early as possible.
Your mentors will provide feedback to your professor or teacher as close to the end of the outreach project as possible, to give you as much time as possible to complete the task.
However, if your PR hasn't been merged, this is not necessarily a reflection on you. The CI often complicates (slows down) PRs merging.
As a minimum, by the end of the outreach project you should aim to:
- Have raised at least two PRs:
- The first PR is your "typo" fix.
- The second is your "main" work item.
- Your typo PR should have been merged.
- The code on your main PR should compile, and include documentation if appropriate.
- If you add unit tests, you'll get extra credit as these are critically important to maintain quality.
Of course! Although you will be graded at the end of the outreach project, you are still allowed to finish any outstanding work after the project officially ends.
Again, of course! Feel free to contribute as and when you wish. All contributions are valuable to the project.