Rework the students section

[svenfuchs]

Maybe this can be changed to "Guides"

I think we should start by putting an "Application Guide" together which contains all the information that is required to submit a good application. So this should cover everything about

• find a pair
• find coaches and a location to work from
• find a project and plan your work

We also might want to rework the FAQ (can we please have a simple plain text version there?)

Later we can then add guides for students, coaches, projects etc. which are more targeted at their roles and explain their job in more detail, give tips and set expectations.

@sareg0, heya :)

[sareg0]

Hey! I agree. Section name 'Students' is a little confusing. Guides, or How to Apply, or Application Guide is better. +1 for changing the section name from 'Students' to something more appropriate.

Okay chronology of rewrites will be as follows;

1. Application Guide (contained here)
2. FAQs
3. Student Guide
4. Coach Guide
5. Project Guide

Below I have done a rewrite which is intended to be the Application Guide. There is some basic styling (bullets and lists), but it looks a little text heavy atm. This could be broken up with styling for better readability. Content is the main focus, atm.

// begin rewrite 1. Application Guide

ALL YOU NEED TO KNOW ABOUT APPLYING TO RGSoC

The goal of Rails Girls Summer of Code is to get you in touch with the Open Source community and allow you to take your first steps in contributing to it. This will be a learning process for you, but we also want to make sure that you have a good chance at succeeding. Please read the application guide below for full details on eligiblity, and application criteria.

Application to the Rails Girls Summer of Code is open to anyone who;

• has attended one or more Rails Girls (or similar) introductory Ruby workshop (link to guides or intro workshops or a part of the site that dictates baseline knowledge, and alternatives for RG workshop).
• expanded their Ruby skills after the workshop in a study group, or independantly, by working on a Ruby project. We will expect concrete coding examples to prove this.
• can spend at least two (ideally three) months of their Summer working on the project.
• has another student to pair up with, and a coach to support you during the project
• is NOT already a professional Ruby developer.
• people of all walks of life, and backgrounds. We favour diversity.

What do I need to apply?

1. A volunteer coach or coaches

You are not limited to how many coaches you can recruit use during your project; you may have one or many. However, you must have access to some who can help you with your project throughout the summer, and preferably for at least a few hours a day. Please try to be specific about the hours/days when your coach(es) can help you. Discuss your project with your coach and make sure they can support you.

Finding a coach in your geographic location is a good idea. Having someone to sit down and troubleshoot with at regular intervals, will increase your odds of having a successful and enjoyable project. Coaches are volunteers, and cannot expect any reimbursement from RGSoC. For an outline of coach responsiblities and expectations, please look here (to be written).

1. Another student to pair with

It is not a requirement to find a pair before applying, but it is preferable. Finding a pair in your geographic region is also preferable. While remote teams will not be discriminated against, it can be more challenging if you cannot work together in person.

Make sure both you and your pair understand the requirements of the project, and could work well together.

1. A place to work

Working at a desk next to your coach, is an ideal scenario. This will give you access to someone who can answer your questions, on a regular basis. You will need an environment conducive to dedicating yourself to your project for 3 months. This could be your home, a coworking space, or your current work office. As long as you are safe and productive, you can choose where you will work.

Note on the above: The best starting point for finding a pair and coach is to contact your local Rails Girls and/or Ruby communities. If you have no luck, or live in an area where there is no RG chapter, ask on the Rails Girls Summer of Code community mailing list (link), and viaTwitter (link). While you are ultimately responsible for finding your pair and coach, we will do our best to help!

1. A project plan

Please meet with your coach and pair to discuss what project you are looking to undertake. Meeting with your coach is a great way to understand if your goals are realistic, and what your project plan will look like.

Together with you and your pair, coaches should be able to:

• talk to you both about your level of your expertise,
• make recommendations about open source projects that you could contribute to,
• help you create as detailed a project plan as possible for your 3 month SoC project.

Lodging Your Application

The application deadline for Rails Girls Summer of Code is _____.

Please lodge only one application per team. If have been unable to find a pair, and need to be connected to another individual and/or coach, please state this in your application.

We will make sure that all the applications meet the criteria, so we'll get back to you if we need more details. Here are some example of previous applications to help you (link).

While RGSoC is open to people from all backgrounds, preference will be given to applications fulfilling the following criteria;

• You are a woman, or self-identify as female. This initiative is focused on bringing more diversity into the world of open source. Men are not excluded, but females will be given priority.
• You have a sufficient experience level (as noted above in WHO CAN APPLY). Please provide concrete examples of what you have done e.g. code examples, Github Account.
• You can participate for the FULL 3 months.
• Your coach(es) has enough time available to guide you.
• You already have a pair.
• Your project's visibility (i.e. a high profile open source project)
• You have a detailed project plan

Once all of you have made sure that you meet the requirements, and selected a suitable project to contribute to, you can submit your application here (link).

Selection Process

Succesful applicants will be informed by ____. Maintainers/mentors, and sponsors who provide coaches, will be involved in the selection process, but their votes will hold equal weight to all others on the selection committee. Applications will be judged on a case-by-case basis by a group of real human beings in the coding community, on an impartial but realistic basis. If there are more suitable students than scholarship places, we will perform a random draw.

Have more question? Take a look at the FAQ, or drop us a line.

[sareg0]

forgive the numbering above... Github comment formatting no likee my numbered list with paragraph text in between... Just take it as an ordered list of items 1-4

[svenfuchs]

Wow, fantastic work, @sareg0!

I think it might be better to talk about "coaches" (plural) as a default in this guide. We explain that there can be one or many coaches, but having a team is better and preferable. So maybe it makes sense to phrase things accordingly?

It is not a requirement to find a pair before applying, but it is preferable. Finding a pair in your geographic region is also preferable. While remote teams will not be discriminated against, it can be more challenging if you cannot work together in person.

I think this needs to be somewhat stronger. Both individuals and remote teams can apply, but their chances will be much lower unless they can explain to us how they're going to make sure they have a good chance to succeed with their project. E.g. if they have trained remote pairing for quite a while, working on something real, and know each other well, then that might override issues we've seen with remote pairing last year. We've also had one team which consisted of only one student and a coach, because they've had an otherwise outstandingly well prepared application.

How about

"It is not a requirement to apply with a pair, but it is preferable. Finding a pair in your geographic region is also preferable. While neither teams with just one student nor remote teams will not be excluded, it can be more challenging if you cannot work as a pair or work together in person. Single-person teams and remote teams will therefor be downrated on some criteria and will need to provide exceptionally well prepared applications in order to be accepted. E.g. if a remote team knows each other well and has already trained working remotely on an existing project for a long time then that might prevent it from being downrated on this criteria."

... although this uses quite some negative phrases. Might be better to put it in a positive way?

Working at a desk next to your coach, is an ideal scenario.

How about "Working at a desk next to your coach is a great scenario. If you have access to a team of coaches who can share the load is ideal."

Note on the above: The best starting point for finding a pair and coach is to contact your local Rails Girls and/or Ruby communities. If you have no luck, or live in an area where there is no RG chapter, ask on the Rails Girls Summer of Code community mailing list (link), and viaTwitter (link). While you are ultimately responsible for finding your pair and coach, we will do our best to help!

I think we should expand this into another section like "How to find a team?". Also, it makes sense for them to create some sort of public resource that one can link to, e.g. on Twitter, and send it around. Like "Here's what we are planning for our application, and we're looking for support xyz"

A project plan

I think we need to be more specific about what we expect. Maybe add something like

"Your application will be rated based on criteria that we think show your chances to succeed with your project. Having a very clear and detailed idea about what exactly you are going to work and how you are going to do this is crucial. The better your project plan the better your chances will be."

Please lodge only one application per team. If have been unable to find a pair, and need to be connected to another individual and/or coach, please state this in your application.

Hmmm, I guess based on last year's experience we should rather not allow them to apply in order to find a pair. This didn't work at all, we just don't have the resources to connect people based on their applications. We might find other ways to do this, e.g. last year there was a huge public Google doc where people were looking for pairs in their city. Maybe we can build on this, but they should only send in applications which they think are complete.

They also may send in applications for alternative projects they have in mind. E.g. last year the work on Sinatra was quite competed for, but only one team could be accepted for it. So I think we can allow teams to apply for alternative projects, but they only should do so if they have a good plan for each of the projects.

Also, one thing that really messed things up was people applying with various pairs. Like 4 people applying in various combinations for different things. They should decide which pair they think makes most sense, works best and has the best chances to succeed, and then stick to this team.

the following criteria

I think we might want to split this list up. We do have baseline requirements (such as "has participated in a railsgirls-like workshop") and we have gradual criteria which their application will be rated on (such as "the more you have invested in continuing to learn programming the better" or "the better support you have the better") ... currently some criteria on that list somewhat sound like binary requirements, e.g. "Your coach(es) has enough time available to guide you." I wonder if we can make more clear here how the rating process will actually work?

Maintainers/mentors, and sponsors who provide coaches, will be involved in the selection process

I'd change this to "can be involved". But then again, I'm wondering if this detail is worth mentioning here. How about just

"Applications will be judged on a case-by-case basis by a selection committee consisting of real human beings in the coding community, on an impartial but realistic basis."

If there are more suitable students than scholarship places, we will perform a random draw.

I might be misunderstanding this sentence, but this sounds wrong. We expect to have way more suitable applications than seats. How about "If there are equally well rated applications competing for a scholarship place then a random draw will be performed."

[svenfuchs]

@sareg0 btw i've just realized that the old application form also contains some text: https://docs.google.com/a/svenfuchs.com/forms/d/158MlfRepVVZh9NjskR7-fuNJz5EsgzRnhrmTD94HXwY/viewform

[katrin-k]

@sareg0 thumbs up for this starter :)

I think the text heaviness can, besides styling, be contained by having the text blocks toggled in (as in the FAQ, but with manual toggle in). Or, as a fallback, have a little menu as a content index at the beginning of the page.

Everything related to "How to find a pair, a coach, a project idea…" should go to the FAQ. At the end of each section there should be a link such as "Read on how to find a pair in our FAQ", "…to find an open source project …".

Concerning the time of the project (2 or 3 months): At the beginning it says "at least 2 months". In the criteria it says "FULL 3 months". This needs to be consistent. I personally vote for full 3 months.

I'll hop over and start polishing the FAQ now.

[katrin-k]

Concerning the requirements/criteria: Last year's FAQ says "we will instead give points to each criterion fulfilled. The higher your score, the higher your chance of being selected."

How did you select the teams last year?

[svenfuchs]

@katrin-k the plan is to have a single page per guide for now, each one containing all the information relevant to the particular topic. please lets not move things to the faq unless they don't fit into the guide well.

I'm very much not a fan of the accordion thing on the faq which just hides text and makes people not read it, and i'd like it to be removed from the faq page.

People can apply with less than 3 months, but that might downrate their application a little bit.

we will instead give points to each criterion fulfilled. The higher your score, the higher your chance of being selected

That could be phrased better. We've got a number of criteria relevant to the question "how are this team's chances to succeed with their project?" Each member of the committee rates the application by giving (as far as i remember) 1-5 points for each of the criteria. These criteria are weighted amongst each other, so some are more/less important.

This way every application gets an overall rating. We'll look at the rated list, look for odd ratings, possibly discuss them in order to find misunderstandings, and correct them if required.

[sareg0]

Okay, so I was taking your suggestions above onboard, as well as inputting some of the text from last year's google forms application page, and improving the text a bit @svenfuchs

I do agree the accordian thing is a bit annoying for me on the ipad... it doesn't work so well :S

Okay, so below I have chopped out as much text as possible, as A LOT is answerable by FAQ. I am trying to focus more on, 'what makes a good application'

// begin rewrite of 1. Application Guide

GUIDE FOR APPLYING TO RGSoC

Once you have read the eligibility requirements, here, and you are ready to start your application, below is what you will need for a great application.

Find Coaches and a place to work

You are not limited to how many coaches you can use during your project, but you must have access to someone who can help you with your project throughout the summer, preferably for at least a few hours a day. Be specific about the days and hours when your coaches can help you.

A roster of which coach will help on which days, is favorable for your application. Discuss your project with your coaches and make sure they can support you.

Finding a coach in your geographic location is advisable, and being able to work with them in their office is even better. Having someone to sit down and troubleshoot with at regular intervals, will increase your odds of having a successful and enjoyable project. Coaches are volunteers, and cannot expect any reimbursement from RGSoC.

For an outline of coach responsiblities and expectations, please take a look at the coach guide, here (to be written).

Working at a desk next to your coach(es) is a great scenario. If you have access to a team of coaches who can share the load it is ideal. You will need an environment conducive to dedicating yourself to your project for 3 months. This could be your home, a coworking space, your current work office, or the office of your coach/es. As long as you are safe and productive, you can choose where you will work.

Find another student to pair with

Finding a pair before lodging your application is extremely advisable. If you lodge your application as a one-person team, your application will hold less weight than those who have a two-person team application. Finding a pair in your geographic region is also preferable, and will be looked upon favorably during the selection process.

Remote and/or single person teams will not be excluded, but their applications must be outstanding. If you are working in a remote team, you will need to provide exceptionally good evidence as to why you will make a good team. If a remote team know each other well and have already trained working remotely on an existing project, then their application will be looked on more favorably, than if not.

It is a requirement to find a pair before lodging your application. Go to some of your local coding or tech meetups to find a team member who you click with.

Make sure both you and your pair understand the requirements of the project, and could potentially work well together. There is nothing more detrimental to project success than an unhappy or unproductive team mate.

Find a project and plan your work

// this needs to have links to specific articles on 'what should my project plan look like' etc. As I have no experience here, I need some concrete examples, or resource to direct applicants to. I welcome any input on this one for sure @svenfuchs

A project can include anything that helps open source like, bug fixing, implementing small features, documentation, design, etc. Projects will be challenging, but simple enough that a beginner will be able to complete their chosen in a time frame of up to three months.

Please meet with your coach and pair to discuss what project you are looking to undertake. Meeting with your coach is a great way to understand if your goals are realistic, and what your project plan will look like. Together with you and your pair, coaches should be able to:

• talk to you both about your level of your expertise,
• make recommendations about open source projects that you could contribute to,
• help you create as detailed a project plan as possible for your 3 month SoC project.

Projects will have:

• a mentor, who will act as an expert to consult on the project, and provide feedback and direction
• coaches who will support the day-to-day work of the students (coaches are developers based in the same city as the student, helping them to accomplish their tasks)

Here are some of the possible projects you could work on: [recommendations please]

Lodging Your Application

The application deadline for Rails Girls Summer of Code is _____.

Only one application will be accepted per team, per project. Please do not lodge one per person. Your team can lodge one application per project than you have a plan for working on.

As some projects are very competitive, and others not so much, you can hedge your bets by lodging an application for each project you would like to work on. This will ensure that if spots fill up for one project, your team can be considered for another. However, each application for each project must be full and complete. Lodging multiple applications for different projects, with different team combinations is frowned upon. Pick one team, and apply for as many projects as you like, but ONLY with that team. If you have an queries about this, please contact us before lodging your applications. While we will try to connect you with a pair and coaches before you apply, but we cannot do so based on your application. Please do not apply unless you have found a pair and coach.

Selection and Judging

Judging will take place from ?? - ?? 2014. Succesful applicants will be informed by ____, 2014. Applications will be judged on a case-by-case basis by a group of real human beings in the coding community, on an impartial but realistic basis. Your chances of success will be the biggest judge of success for your application.

If there are equally well rated applications competing for a scholarship place, then a random draw will be performed.

//end rewrite

How to find a Coach and Team: I thought we could put this in the FAQ section. I have written an article for it, but we could go through FAQs once we have the application guide finished, so I have put that aside.

[sareg0]

I have neglected 'selection/judging criteria' here... I think that was very confusing for participants, so until we either decide to make the entire judging matrix transparent, or have a really clear idea on it, I won't put it in the application guide... It seems to cause more confusion than clarity, and can be read to many ways ;) Main thing lacking in the above is the guide on how to write a good application, and project plan, and how to select a project... e.g. Do we suggest them, or do they just find them themselves?

[svenfuchs]

@sareg0 awesome work!

I think we should just publish this on the site as soon as possible. We can still make changes to it once it's online (and actually, we can then use pull requests and make use of the shiny new prose diffs github now has :)

Regarding a list of potential projects: we don't have one, yet. I think we should do an official "Call-for-Projects" and organize this as issues in a separate GitHub repository. Conferences have done their CfPs using GitHub issues with great success.

Regarding criteria for a good project plan: that's pretty hard. We don't have an official list, and I'm not sure it is possible to have one. Maybe we could list some recommendations, but eventually the project plan very much depends on the student's skills, the coaches, and obviously, the project. Need to think more about this.

One minor nitpick:

Finding a pair before lodging your application is extremely advisable.

vs

It is a requirement to find a pair before lodging your application.

This seems somewhat contradictory, but I think what you really mean in the second sentence is that "if you want to apply with a pair, then it is a requirement to find her before lodging your application"?

[svenfuchs]

Regarding the faq ... what's the english term for a drawer or bag where one just throws all the stuff in, and ends up creating a huge mess? faqs tend to end up like that :)

I think it would be a good idea to answer the question "How to find a Coach and Team" on the application guide page, maybe as a separate section at the end of the page. Once we have all the text in place we might want to consider splitting things up a little bit more, maybe on two or three pages. But we should have all the information relevant for the application on this page, and finding coaches is one major concern here.

[sareg0]

Sure, those two sentences do seem contradictory.

As a matter of clarity do we want only applications from teams?

If someone is looking for a pair do they lodge an application and select a certain option, or is there another way we can help them find a pair?

If we can specify 'if you have a team do this if you don't do that' and include the finding a coach and pair explanation in the directions for people without a team.

So I understand. Do we have a formal way for these people to find coaches and pairs?

This is the text I have prepared thus far, but could be improved.

[sareg0]

//begin 'how to find coach and pair' copy

Finding a Coach and Team The best starting point for finding a pair and coach is to contact your local Rails Girls and/or Ruby communities. This is good for people who are looking for guidance on project ideas, as well. If you have no luck, or live in an area where there is no RG chapter, ask on the Rails Girls Summer of Code community mailing list (link), and via Twitter (link).

Make the most of your local dev communities. If you already have a good project plan, and are looking for a coach, a team member, and/or a work space for you project. We have a protocol for a 'Call for Action' on your project plan which can be found here (to be written... how to send out your project plan to fish for a team). ]

[svenfuchs]

As a matter of clarity do we want only applications from teams? If someone is looking for a pair do they lodge an application and select a certain option, or is there another way we can help them find a pair?

No, we don't want the application process to be used as a means to find pairs (or coaches, or projects, ...). We want complete applications to be submitted. Still, a complete application can be for a team that only has one student (something we've accepted last year, too). Pairs will be favored, but exceptional applications for single-student teams have a chance, too.

The text about finding a coach and team seems good to me.

Not sure what "We have a protocol for a 'Call for Action' on your project plan which can be found here" exactly means. Maybe I'd just skip that sentence for now.

Once we have a list or tool for people to look for pairs and coaches then we can link that here, too.

Let's get this text published, shall we?

@sareg0 would you be able to add the text to the site yourself? Would you need help to get set up with Jekyll? Or should we find someone else to add it?

[anikalindtner]

woha! just wanted to chime in and say: great work! this looks good <3

[sareg0]

Thanks @anikalindtner. No problem.

@svenfuchs agreed. Bit of an awkward sentence. Never used Jekyll before but my boyfriend said he'd give me a hand and we'll have it up latest tomorrow evening. Does that work? One can always make changes and updates once it is published, like you said.

Cool. I'll get that up

[berlintam]

Just gave this a quick read - looks great and definitely clears up some of the confusion from last year. Maybe a small suggestion but not sure if this'll be too much work/too much for applicants to read: how about some examples from successful applicants last year? It might help minimize the number of (inevitable) confused emails coming in from applicants if they have an example to work off of.

[berlintam]

A few more things:

• I think it's a tad unclear still about who this is for (and perhaps also in my mind). Is RGSoC for total beginners? Advanced beginners? Both? Somewhere in between? The only place where 'beginner" is used is in the projects section where is describes the complexity of the project. A simple sentence at the top of the page will clear this up.
• @FrauBienenstich has also pointed out that we may want to be clear (if this is the case) that this is for people who want to make a career change/who are on the path to become developers, not just for the average person who is trying out coding for now. Perhaps though this falls into a different section about the general RGSoC philosophy. Apologies if this is repetitive/has already been discussed somewhere else.
• I think it's also important to mention that you don't have to be a university student to participate, especially considering the word 'student' is used throughout the website.
• holiday (I referenced this in rails-girls-summer-of-code/rgsoc-teams#61 ). Are teams allowed a week off? Do we have a holiday policy? Do they have to declare this ahead of time? Are teams with previously scheduled holidays going to lose points in the selection process?

[svenfuchs]

@berlintam that's super valuable input, thanks!

I like the idea with the example application, although I'm very hesitant to publish actual data. Maybe we could instead, based on actual experiences from last year, come up with anecdotic/narrative examples that illustrate what worked well. E.g. summarize in a few sentences what made environments like soundcloud/absolenta work this well. I probably wouldn't add these to this page, but have a separate page to where the application guide can link. WDYT? @berlintam would you be able to help collecting and writing these examples?

You are right that we need to be more clear about our target group. No, RGSoC is not for total beginners. Actually the original goal was to provide a longterm goal for students to continue learning (obviously last year we had to make some compromizes there, since it was the first year). I think we can add a sentence or two to the top of the application guide for now, but later on we'll need a more complete page about "What is RGSoC?" which explains not only its purpose, but also structure, implementation etc. a little bit more. There also should be a very short version on the homepage, which links to the page.

Would that also answer the question about the career change? We've never put it that way, it's an interesting one. We've always put emphasis on the open source aspect, and we should stick to that. But it certainly implies that people are generally interested in "becoming a developer" rather than "play with code".

+1 to making more clear this is not about university students ... at all.

Re holidays: you are right, we need to clarify this. I think we had one team who took one week off during the summer, but also extended the program by one week after the normal schedule. This can be allowed, but we'd favor teams who work for 3 months in total and have a reasonable schedule (e.g. taking 2 weeks off after working for one month might not be a good approach since this is about learning). So, yes, this should be clarified in advance.

[berlintam]

@svenfuchs about the sample application: I don't mean real data either, sorry, I should have made that more clear. I can do this, yes. I can browse past blogs, send emails and come up with a few good points on what worked last year. I won't have time today, but I can get started tomorrow and produce something rough to work off of. Where would I put this in terms of a github location?

As for the career change, I suppose it's just something I kind of assumed since I think most of the teams in Berlin made a career change post RGSoC. Perhaps it's just a happy coincidence. :smile:

[svenfuchs]

Cool!

Any place is good, but I guess it would be easiest for others to

• either just open an issue and paste text as @sareg0 did
• or add a page to the site (e.g. /student-application-examples-draft) and send that as a pull-request

The latter option allows to do inline comments, which might structure discussion a little bit better. But you can also just kick things off by opening an issue for starters.

[anikalindtner]

Do we want something like i did for /fag? For a text that is a bit longer this might be a nifty thing to keep the overview? wdyt?