GSoC Proposals are Due at 15:00 (EST) on Friday March 25th

[Remy DeCausemaker]

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(a)redhat.com&gt;
https://whatcanidoforfedora.org