- Mentee/Mentor Bonding Period
- Mentee expectations
- Evaluations
- Participation at an industry event
- Resources for Mentees/Mentors
- Further resources
Thank you for your willingness to participate in the Open Mainframe Project Mentorship Program. This document is a guide to the program as an intern.
Much of the inspiration and content for this manual comes from the Google Summer of Code Manual, a big thank you to Google for providing this valuable resource.
You should also review the goals and processes of the Open Mainframe Project Mentorship Program to familiarize yourself with the overall program.
This 2 week period kicks off the mentorship program and is a chance for mentors and mentees to learn how to work together.
Here are some of the goals of this period:
- Prepare yourself to immediately start writing code at the official start of coding.
- Get yourself engaged socially in the project.
- Provide time for you to learn about the development practices of the project.
- Ensure that you have a development environment set up. This includes getting set up with the project version control system and reading up on necessary documentation.
- Further refine the strategic plan for project completion and submit it with mentor approval to the Open Mainframe Project Mentorship Program Administrator.
- Get required forms filled out, such as the tax forms required by the Linux Foundation, any contributor license agreements, and any paperwork that your project requires.
Successful completion of your project depends a lot on the bonding period. Make sure that you and your mentor make good use of this time and make significant progress on preliminary tasks. The mentee/mentor bonding period is also a good chance for you to start interacting with other mentees. Early connections can help you get support from other mentees during coding.
The last thing you want is for the coding period to start and then realize that you don't have all the tools you need installed and configured to actually begin work. Don't let this happen to you! The community bonding period is the perfect time to get these things sorted out.
Each project has a unique set of tools and packages required to work with developers. These often include:
- Compiler
- Language interpreter
- Text editor
- Version control system
- Modules and libraries needed by the software
- Database, mail or web server
- Real-time communication tool (e.g. Slack)
Some projects require testing on multiple operating systems and/or platforms. Make sure you know what is expected of you as early as possible. Read the available development documentation and contact your mentor to figure out exactly what tools you need to succeed. Also learn the the bug-reporting process that your project uses and also understand the the project's release management strategy.
Once you get your development environment setup start practicing! This includes getting familiar with the coding standards, codebase, and testing and documentation policies of the open source project community. Do a few practice commits and work on understanding how source control works within your project. Brush up on any new skills and start asking questions.
Look through the project's bug database and read through the user list to understand your end users. Peruse the mailing list archives and go through the project's existing documentation.
Take advantage of the community bonding period to connect with your mentor, and other mentees in the program. Set up a blog, get involved on relevant forums and mailing lists and in general, start interacting with the development community. Make sure you have what you need to succeed, and if you don't, ask your mentor for help.
Open Mainframe Project Mentorship Program is not only about working with your mentor. There's this amazing group of outstanding and motivated mentees too.
There is Slack channel in the Open Mainframe Project for project mentees. Go ahead and introduce yourself on the intern Slack channel. Talk about your project ideas, get feedback on your proposal. There are also program participants in this channel from earlier years. Use this Slack channel as an additional resource. Your questions can be technical or non-technical. Of course, remember not to be a bullhorn and be mindful of proper etiquette.
There are many mentees who have faced or are facing the problems like you. Don't be scared to ask your questions. This is more true for the mentees who have been accepted to the same organizations as yours. You can ask them about how they got their dev setup working. Help each other out on the irc and mailing lists. Don't be afraid to ask and don't be afraid to answer!
This program is a great opportunity that helps people and communities collaborate across boundaries. Use this opportunity to learn more about diverse technologies and cultures and be respectful of the cultural differences.
You can always find mentees who are excited by the same ideas as yours. Use your program contacts to organize meetups and discussion groups. You can meet up with people who are. It's always good to put a face on the names that you've been friends with. Help each other out with coding problems.
Do you have a good project schedule? Have you informed your mentor of any planned absences? Make any project adjustments you may now recognize as necessary based upon getting your dev environment setup and your new understanding of how the project works.
The nature of the program means that mentees are required to be self-starters and proactive. Your mentor is here for advice and support - but not as a babysitter or micromanager. Your success depends on your ability to fulfill the following qualities successfully.
Ideally, you have already worked with your mentor to layout a clear schedule for regular meetings, reports, code check-ins and any planned time off. If you haven't, do this now!
Your mentors are busy people too. They are juggling many tasks and this program is one more added to their load. If you rely solely on your mentor to keep track of and enforce the schedule of work, your project is almost guaranteed to fail. Be proactive in keeping the schedule you've agreed to and proposing modifications before deadlines pass.
Your mentor is volunteering her time to help you with your project. Regularly missing scheduled meetings without prior notice and failing to come prepared to meetings is likely to cause your mentor to not want to continue helping you with your project. Remember your mentor is your most valuable resource to help you complete your project successfully, treat them accordingly.
During the coding period, you should continue to make full use of your mentor. As you implement each phase of your project plan, ask your mentor for feedback on the code as you go. Avoid working for two weeks on a chunk of code that is headed in the wrong direction.
Never be afraid to ask questions, but remember you are going to be more successful in receiving a good answer if you try to be specific and do a bit of background investigation first. Take a look at logs and try to think through the error or problem before asking for help. Equally important is to not wait until you are significantly behind in your project to ask for help.
Hearing criticism can be hard. It can be even harder to not respond defensively. Asking for and receiving constructive criticism about your project from your mentor, the larger open source project community and your peers is an invaluable exercise to help you write the best code possible.
During the community bonding period you and your mentor should have established a schedule for regular communication about your project progress. But what if you want additional feedback or maybe you aren't getting a very detailed response from your mentor. How do you go about asking for additional critique? A general "how am I doing" is going to probably get you a general "you are doing fine" response back. Instead, do your best to ask specific questions about specific areas.
First, take a deep breathe. OK, now take another. Chances are your mentor is not wrong and you need to listen to their advice. This is a great opportunity to start asking questions. Try not to be defensive but rather, "I really don't understand what you mean, would you please explain?". Remember that the open culture surrounding most open source projects encourages and thrives on discourse. Don't view the feedback as negative criticism, but rather an opportunity to explore how to do something different and make your project better. Do your best to listen, learn and incorporate feedback into how you work.
One of the best things you can do when working to solve real or perceived problems with your mentor relationship is to stop and remember that your mentor(s) is a volunteer and has non-Open Mainframe Project Mentorship Program responsibilities.
So you haven't heard from your mentor in a while, what do you do? First, did your mentor miss a scheduled meeting or did he just not respond immediately on Slack or to an email?
If you didn't get an immediate response outside of scheduled meeting times either on IRC or email, be patient.
If your mentor missed a meeting, then a gentle email along the lines of "did I mix up our meeting time" to your mentor is a great idea. Chances are you'll hear back shortly and things will continue on as planned. If you don't hear back, then try contacting your secondary mentor and if there is still no response, then contact the Open Mainframe Project Mentorship Program Administrator.
Remember that everyone has different communication styles and you might both be communicating in a second language. Providing project critique is part of a mentor's job. That being said, if you feel like your mentor is being unduly harsh and it is affecting your project success the best approach is to talk with your mentor about thier communication style in a non-confrontational manner. If you still feel like your mentor is being unduly harsh - after your conversation - talk to the Open Mainframe Project Mentorship Program Administrator.
Again, this could be a disconnect based on different communication techniques within different cultures. Make sure you let your mentor know what about their style is making you uncomfortable. If things don't change for the better, contact your the Open Mainframe Project Mentorship Program Administrator.
Efficient time management goes a long way in helping you make the most of your program experience. You and your mentor should come up with a custom time line that fits in well with your project requirements and also with your plans for the summer.
The following are some suggestions that can help you to manage your time well:
There's already a complete section in the manual on this. (It is that important.) Use this time to get familiar with your community, setup your development environment and get an early start on the code development. This is time where you're getting to know your mentor and other mentees. Chat with them on Slack, ask questions and share ideas on projects and get ready to begin the fun ride ahead.
This program is a job and needs an investment of about 40 hours a week ( unless this is done as a class project - in that case consult with your academic institution instructor for guidance ). If you know in advance that you'll need to take a couple of days during the summer of code, you should communicate that with your mentor beforehand and plan to make up for lost days.
You should absolutely, absolutely make sure you're interacting often with your mentor through mutually agreed upon communication channels. It is extremely important that you and your mentor are on the same page in terms of the project status and plans. Your mentor is your biggest resource and you should make sure that you capitalize on that well.
It always helps to set short-term goals that you can discuss with your mentor. Breaking down your project in smaller tasks helps in many ways:
- It gets you started!! You have a smaller, well-defined task to work on which is easier to manage.
- Mini-goals help create a road map to get to the final output you're trying to produce.
- Smaller goals are less daunting, and completing a small goal gives you the confidence to tackle the next one.
Regular code reviews are extremely important for staying on track. Don't be afraid to ask for them as frequently as you need them. It is much better to ask for a code review after 10 or 20 lines instead of hundreds of lines. If your mentor tells you that you are going about something the wrong way, you don't want to find out after writing a ton of useless code.
Keeping a log of your progress is a great way to monitor progress both for yourself, your mentor and anyone else. It also turns out to be valuable in cases when you need to go reconsider a decision and figure out why you made that choice in the first place. Blogging is a good way to achieve this, since you may get good advice in the way of comments from people that you normally wouldn't communicate with, and it gives you a bit of limelight as well.
It's very likely that your mentor is in a different time zone than you are. Be sure that you take this into account while you're preparing your plan. Time zones should be included for any meeting times, and UTC is often the best time zone to use, since it is not affected by Daylight Savings Time.
Things usually don't go the way you plan them. Make sure you have room for the unplanned changes. It's always best to keep aside some buffer time that you can use in case you do digress from your original plan and save yourself from considerable pain and panic attacks.
Of course, do remember that this program is not just all coding and working. It's about having fun too! If you manage your time well, you will have a great mentorship, meet interesting people and have lots of fun.
Just like using the GitHub wiki for doing the project strategic plan, a great practice is to document progress weekly in the GitHub wiki. This doesn't need to be a complex in such a way that creates a burden on the intern or the mentor; a simple wiki page with a list of milestones completed, milestones to be addresses in the next week, and milestones yet to do is perfect and helps structure the weekly meetings. Here's an example:
Done in the past week
- Added function X
- Fixed outstanding issue Y
To do this week
- Add new feature A
- Fix regression B
Still outstanding to do
- New Feature C
- New Feature DEvaluations occur twice during the program (midterm and final). They are your opportunity to evaluate your mentor and your mentoring organization's performance. This is also your mentor's opportunity to evaluate you.
The pass or fail decision from an evaluation should not come as a surprise. You and your mentor will already be communicating, and you should be discussing the quality of your code, your participation in the community and your progress on your project to that point. If you aren't getting this feedback, ask for it.
Evaluations are a survey that both you and your mentor fill in during the evaluation period. Open Mainframe Project will put a system in place and publish the evaluation questions for both mentees and mentors in advance.
Evaluations will take about 20-25 minutes to complete. The questions focus on the scope of your project, the quality of your interactions with your mentor and your community. You, your mentor and the Open Mainframe Project Mentorship Program Administrator will receive an email after the evaluation window closes that tells you whether you've passed.
Your evaluations are only visible to the Open Mainframe Project Mentorship Program Administrator. In some cases, Open Mainframe Project program administrators may need to share some details of evaluations with you and your mentor. This may happen, for example, when evaluations indicate a payment should not be made.
If you or your mentor do not submit an evaluation, you fail and will be removed from the program. Similarly, failing an evaluation means you are immediately removed from the mentorship program.
At the end of the mentorship program term you are required to provide a link to the work you created during your current mentorship participation, in addition to your evaluation. Essentially the target of the link should contain a short description of what work was done, what code got merged, what code didn't get merged, and what's left to do.
Depending on what portions of code are included in the scope of your project, you may need to submit diffs between code that you've written and others have written, or even include an entire branch of the code base. Discuss this with your mentor and your community and use your best judgement.
Successful completion of your evaluations triggers the payments to your account. This takes a few business days to process. Please be patient.
The Open Mainframe Project invites passing mentees to present at an industry conference at the end of their term. This provides a unique opportunity for the mentee to share their work with a broader audience, as well connect with potential employers. Mentees are excepted to act in a professional manner while at this event as you are a representative of the Open Mainframe Project and the project you contributed to.
Open Mainframe Project will cover travel expenses and incidentals for the mentee to attend, including:
- Prepaid transportation and hotel
- Local transportation
- Meals up to $100 USD per day
Expenses will be reimbursed after the event up submission of the receipts and an invoice to [email protected].
The Open Mainframe Project provides the following tools for both project management and collaboration.
The Open Mainframe Project Mentorship Program GitHub organization will host all mentee projects. GitHub provides source code management, issue tracking, and wiki collaboration tools that should be leveraged by the mentee and mentor during the program.
Action for mentee: When you have determined your project, contact the Open Mainframe Project Mentorship Program Administrator and provide your GitHub ID, and either the name of the project if it's newly created or the URL for the existing project repository if you will be working off a fork of an existing project.
The Open Mainframe Project has a Slack service for community communication, and encourages all mentee/mentor communications to leverage Slack. Slack provide instant messaging, audio/video calling, and recording of historical conversations.
Action for mentee and mentor: Sign up for a Slack account. The Open Mainframe Project Mentorship Program Administrator will create a channel for communications specific to your project.
Students can leverage the LinuxONE Community Cloud for a development and testing environment for their projects. These instances are available at no charge and allow a free instance for use for up to 120 days.
Action for mentee: Sign up for an account
More details on mentee best practices and process are found in the Google Summer of Code Student Guide. This program was inspired by the GSoC program.