SOC Writing Project Proposals - Revision history

Marko: /* More Links */ hm, no need fo rthat, it's actually in the URL itself and also in the web page

2012-05-25T10:55:33Z

More Links: hm, no need fo rthat, it's actually in the URL itself and also in the web page

← Older revision		Revision as of 10:55, 25 May 2012
Line 66:		Line 66:
	== More Links ==		== More Links ==

	* [http://web.archive.org/web/20110209000900/http://shlang.com/writing/soc2005.html ''Google's Summer of Code 2005: Experience of One Mentor''] ~~<small>(original URL at [http://www.internet2.edu/~shalunov/writing/soc2005.html])</small>~~		* [http://web.archive.org/web/20110209000900/http://shlang.com/writing/soc2005.html ''Google's Summer of Code 2005: Experience of One Mentor'']

	[[Category:Developer Documentation]]		[[Category:Developer Documentation]]

Marko: + archived URL

2012-05-25T10:54:56Z

+ archived URL

← Older revision		Revision as of 10:54, 25 May 2012
Line 66:		Line 66:
	== More Links ==		== More Links ==

	* http://www.internet2.edu/~shalunov/writing/soc2005.html		* [http://web.archive.org/web/20110209000900/http://shlang.com/writing/soc2005.html ''Google's Summer of Code 2005: Experience of One Mentor''] <small>(original URL at [http://www.internet2.edu/~shalunov/writing/soc2005.html])</small>

	[[Category:Developer Documentation]]		[[Category:Developer Documentation]]

BryceHarrington at 09:19, 12 March 2008

2008-03-12T09:19:16Z

← Older revision		Revision as of 09:19, 12 March 2008
Line 55:		Line 55:
	* Solicit users to test out your new feature, and encourage them to submit bug reports and feature requests. Triage which of these you can do, and do them.		* Solicit users to test out your new feature, and encourage them to submit bug reports and feature requests. Triage which of these you can do, and do them.
	* Write a short article for an online publication about your work		* Write a short article for an online publication about your work

			=== Include Mockups ===

			If your feature will involve GUI dialogs, configuration settings, or canvas drawing, be certain to sketch up some examples. Not only is this helpful during review, but it will help you out greatly later when you're deep into the coding.

			== Unit Test ==

			Early in your development, perhaps after initial proof of concept stuff, but prior to the midterm, write a unit test, that will exercise the functions in your feature. The unit test should feed in dummy test data, and verify that correct output or data structure changes are performed.

	== More Links ==		== More Links ==

BryceHarrington at 09:11, 12 March 2008

2008-03-12T09:11:39Z

← Older revision		Revision as of 09:11, 12 March 2008
Line 9:		Line 9:
	own judgement, but on this page are some suggestions that may give you some		own judgement, but on this page are some suggestions that may give you some
	inspiration.		inspiration.

			=== Get Feedback Before Submitting ===

			Without question, the best proposals have come from students who took time to share their proposal on our mailing lists and solicit feedback. This ensured their proposals matched up better to what the Inkscape community wished, and it also gave the community a chance to get to know the student. Both of these resulted in much higher scoring, than proposals that came in anonymously.

	=== Don't Bite Off More Than You Can Chew ===		=== Don't Bite Off More Than You Can Chew ===
Line 30:		Line 34:
	so that you "should be done" within 2-3 weeks; that way when reality sets		so that you "should be done" within 2-3 weeks; that way when reality sets
	in and it takes 2-3 months, you're not totally screwed. ;-)		in and it takes 2-3 months, you're not totally screwed. ;-)

			Indeed, we will be expecting to see a "mostly done" code delivery at the midterm. Students who don't deliver something that mostly works at this point risk being dropped.

			If things go well, for the second half of the summer you should be focusing on fixing bugs, making improvements requested by users, fixing bugs, documenting, fixing bugs, and filling out GSoC paperwork.


	=== There's More to Open Source Than Coding ===		=== There's More to Open Source Than Coding ===

Colin Marquardt: /* More Links */

2006-06-21T16:20:02Z

GigaClon: Categorization

2006-06-21T16:07:11Z

Categorization

New page

== Writing Project Proposals ==

If you're thinking about writing a proposal for one of the Google Summer of Code
projects, you might be uncertain about a few things. How big of a task should you
propose? What should you include in your proposal? How can you make it more
acceptable?

Of course, you will have to decide the answers to these questions with your
own judgement, but on this page are some suggestions that may give you some
inspiration.

=== Don't Bite Off More Than You Can Chew ===

Remember that this effort is date-scoped. This is a little unusual for Open
Source projects, but is common for contract work. But don't panic, there are
some techniques to ensure you will succeed at achieving this.

First, be very careful about what you commit to delivering. If possible,
try to pick things that you already know how to do pretty well and won't
need to do a lot of learning and research. This way, you'll be less likely
to find yourself halfway done and realizing you've bitten off WAY more than
you can chew. Of course, you can probably list some "optional" delivery
items for things you're less certain about.

Second, try to weight your schedule to get the key portion of the project
done as early as possible. In other words, try to do 80% of the coding
in the first 20% of the time. The reason for this is that the last 20%
of the project often seems to take 80% of the time (no one really knows
why, it just always works out that way.) So try to set your schedule up
so that you "should be done" within 2-3 weeks; that way when reality sets
in and it takes 2-3 months, you're not totally screwed. ;-)

=== There's More to Open Source Than Coding ===

It's very common to assume that most of the work of implementing a new
feature is just writing code. Sometimes that is in fact the case, but
it's much more common that the coding is just a small part of the effort.

Since the purpose of Google's sponsorship is to increase your knowledge
of Open Source, make sure your project includes these other kinds of
activities:

* Survey the Open Source world to see if anyone else has done something like your feature; if so, analyze what they did, and borrow ideas and algorithms from it
* Create good code documentation for code affected by the change
* Create a tutorial that shows users how to use the new feature
* Solicit users to test out your new feature, and encourage them to submit bug reports and feature requests. Triage which of these you can do, and do them.
* Write a short article for an online publication about your work

== More Links ==

* http://www.internet2.edu/~shalunov/writing/soc2005.html

[[Category:Developer Documenation]]

← Older revision		Revision as of 16:20, 21 June 2006
Line 51:		Line 51:
	* http://www.internet2.edu/~shalunov/writing/soc2005.html		* http://www.internet2.edu/~shalunov/writing/soc2005.html

	[[Category:Developer ~~Documenation~~]]		[[Category:Developer Documentation]]