Skip to content

Latest commit

 

History

History
149 lines (103 loc) · 7.13 KB

README.md

File metadata and controls

149 lines (103 loc) · 7.13 KB
Raw

GSoC @Sugar Labs

Shortcuts

GSoC'22 Ideas Proposal Template Sugar Labs @GitHub

Introduction

Google Summer of Code is a global program focused on bringing more student developers into open source software development. See GSoC 2022 how it works

Sugar Labs is a Google Summer of Code 2021 mentoring organisation.

Our archives of GSoC Projects: 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019 | 2020 | 2021

Want to work with us ?

Please get involved. Familiarise yourself with our code, by reporting and fixing bugs.

See our ideas page. We would love to hear your own ideas as well.

You may use our proposal template or your own.

In addition to the Google Summer of Code requirements for a proposal, proposals for Sugar Labs;

  • must be your own work, and not the work of others, except where the work of others is minimal, duly credited and quoted,
  • must show you are fluent in the programming language needed,
  • must show your assessment of the competency of your mentors,
  • should be posted on our sugar-devel@ mailing list as GitHub Markdown or PDF, and supported with answers to any questions posted in reply,
  • should not be posted to our sugar-devel@ mailing list as a Google Docs (a document can change after you send the link, a document can disappear, the export feature may be turned off, and we don't want to require our members to use Google Docs).

For students who wish to be able to delete their proposal after failing to win a project, please do not post it on our mailing list. Our decisions will be based on the contents of the final PDF proposal and our interactions with the student.

How to talk to us ?

We use the sugar-devel@ mailing list for communication. Join to participate in the discussion and ask for help. Allow some days for reply. See Community etiquette.

Do not write secretly to mentors or developers unless they have asked you to. This varies by idea. Check the list of coding mentors for each idea. We have added contact methods.

How to Contribute

At Sugar Labs we have opportunities for contributing with many different programming languages and libraries.

Getting Help

Got a problem? Ask your mentors, ask other students, or ask the Sugar Labs community.

The Sugar Labs community is large, and there are people who are not mentors in the contest. Mentors are listed. Everyone else you talk with may be a non-mentor.

Students should keep in mind that some people are non-mentors, and cannot see the contest progress, dates, or information about students. When communicating widely, be sure to;

  • Introduce yourself, the first time,
  • Talk about the task as if you want to do it yourself, not because of the contest,
  • Defend your technical decisions without using the contest as a defense,
  • Non-mentors may give good guidance on technical decisions, but bad guidance on how they think a task is judged. Always consult with your mentors as well.

Community etiquette

Everyone in the community has to be polite and respectful, and consider everyone else a member of a team and not a competitor.

One should be considerate to everyone else's time. We would like to have quality discussions, and not answer questions that are already documented, or available on stackoverflow. This doesn't mean you can't ask questions, but a clueless user and a lazy developer are two different things.

Tell things as you see them. Be polite, but don't sugar coat it. You don't have to apologize everytime you make a mistake; but avoid repeating it again ;-)

Also see our Code of Conduct

Right fit

When we start interacting with you during the application period, we have several ways to see if you are the right fit; see how you compare to our perfect student;

  • you have a GitHub profile with a history of commits, pull requests, and issues in our project, other projects, or personal projects,

  • you are patient to apply every suggestion during a pull request review,

  • you care about our project beyond the specific task you are working on; you care about changes to documentation, tests, releases, issues, etc,

  • your conversation with us is more than the topic you are working on, but flows naturally to any topic,

  • you are able to have a proper technical discussion; and understands the value of the discussion in itself,

  • you don't just say yes and do something because a mentor says so,

  • you are interested in our community and follow our code of conduct and guidelines,

  • you keep working with our community even if you are not accepted,

  • you have contributed to our project before the application period,

  • you can engage in tight feedback loops around design discussions in proposal drafts,

  • you don't ask for help to write a proposal,

  • you don't remain ignorant of our software or what our project does,

  • you always write in public, and never write to a mentor in private unless the mentor has asked for that,

  • you work on a project our community needs, regardless of your personal interests,

  • you don't just fix issues, but you also get involved in other people's work.

(abstracted by @quozl from a work-in-progress document shared among mentors of several organisations, titled "Tips for finding the right GSoC student for your org".)

Cheating

When we suspect cheating we are to report it to the GSoC coordinator. We have a list of behaviours we look for. We don't make that list available.

Your proposal, source code and other submissions must be your own work, and not the work of others. Except where the work of others is minimal, and duly credited and quoted. See Cheating.

Thanks for reading all the way to the end!