GSoC-ers, Welcome welcome welcome! I've seen a few folks introduce themselves here and in the IRC channels, and have seen increased activity in our issue trackers and wiki pages. I'm excited to read more about what you are excited to work on during this round. Here are a few tips for what we're looking for a GSoC applicant and proposal: 0) Communication Remote work and collaboration requires us to stay in touch with eachother in many different places. It would be a good idea for folks to be available in IRC, and hanging around in #fedora-summer-coding and then any other channels that relate to your proposed projects, such as #fedora-commops, #fedora-hubs, #fedora-apps, #fedora-docs, and any others that interest you. Be sure you are subscribed to the mailing lists, and be present when you can. 1) Self and Group Direction Mentors, though committed to GSoC, have other full-time commitments in addition to their contributions, much like any FOSS community. Due to this fact it is extremely important that we all communicate publicly and openly, so that we can work together and mentor eachother. It is also important that when you as a student come to ask a question, that you have looked thoroughly through the available resources about our GSoC program. Our admins and mentors have put significant time and energy into crafting our information pages, so please use them. Our organization page is the best place to start https://summerofcode.withgoogle.com/organizations/5630777857409024/ and other GSoC resources can be found at http://etherpad.osuosl.org/fedora-gsoc-welcome-2016 2) Self-selection, autonomy, and not blocking One thing that keeps Open Source contributors engaged and successful is self-selection. You are more likely to contribute towards something that YOU are passionate about. In your proposals, be sure to look at the idea page as the foundation, and then dive *deeper* into that corner of the project. The project's issue tracker pages are usually the best place to find pieces of your proposal. Dig into mailing lists (that's why they are public lists.) Find out if anyone has been talking about your proposed ideas, and who is talking about them. We are not here to tell you which thing is most exciting to you--you should be telling us. Don't block. If you find yourself unable to make progress in one area, then likely there is another area where you can. If you haven't gotten a response to your question in a private email, then try asking that question on the public lists where more people are likely to see it. 3) Directions and Details When making estimates in a software project, there are often unanticipated bugs and setbacks that arise during development. Having a specific plan helps keep a project moving towards goals, but keeping that plan flexible is important. A good plan will be specific enough to stay on track, but not so specific that it can't change. A good approach is to come up with a calendar with weekly themes, and give yourself a little bit of extra time than you think you'll need. Yes, this is Google Summer of CODE, but you'll need to include time for writing things other than code such as blogposts, documentation, planning and preparation materials, and email updates in your proposal as well. tl;dr - Start with existing ideas, typically from a project's issue tracker. Set weekly goals, with specific activities listed for periods of 2-5 days. Include time for evaluation and reevalutation. I am going to do my best to review everyone's proposals and prepare feedback by End of Business tomorrow night (3/22.) Be sure your proposal is either in the wiki according to instructions, or in a collaborative editor like etherpad (http://etherpad.osuosl.org.) Happy Hacking, --RemyD. -- Remy DeCausemaker Fedora Community Lead & Council <decause@xxxxxxxxxx> https://whatcanidoforfedora.org _______________________________________________ summer-coding mailing list summer-coding@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/summer-coding@xxxxxxxxxxxxxxxxxxxxxxx