From e7366bf41f68cfe07e9ea03fc4a398baecbae651 Mon Sep 17 00:00:00 2001 From: Daniel Silverstone Date: Sat, 4 Feb 2017 09:41:13 +0000 Subject: Initial conversion from MediaWiki, 20170204 --- gsoc/requirements.mdwn | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 gsoc/requirements.mdwn (limited to 'gsoc/requirements.mdwn') diff --git a/gsoc/requirements.mdwn b/gsoc/requirements.mdwn new file mode 100644 index 0000000..4d4dfc7 --- /dev/null +++ b/gsoc/requirements.mdwn @@ -0,0 +1,85 @@ +[[!meta title="GSoC/Requirements"]] +[[!meta author="James Bursa"]] +[[!meta date="2009-05-27T01:14:50Z"]] + + +[[!toc]] + +Basic requirements for GSoC students +------------------------------------ + +Students are expected to work a "standard" work week. Anything above +that is fine too, but we expect a commitment similar to normal +employment. After all, Google are paying for your time. + +Expectations for communications +------------------------------- + +The NetSurf team use IRC, so you will be expected to be on \#netsurf on +Freenode and communicate there. + +Each week, (or more often if suitable) you are expected to send a report +to your mentor indicating what you have achieved, what you intend to +achieve over the coming week, and anything which is blocking you from +proceeding. Your mentor will then post to the netsurf-dev mailing list +providing a redux of this information suitable for others. + +If you have any issues with anyone else, you are expected to take it up +with your mentor, or if the issue is with your mentor, with one of the +other mentors in the project. The mentors are: John-Mark Bell (jmb), +Michael Drake (tlsa), Rob Kendrick (rjek) and Daniel Silverstone +(kinnison). + +Who to talk to +-------------- + +Your mentor is your first point of call for anything directly related to +the running of GSoC. They are the person responsible for your midterm +and final assessment and you should be using them for this. + +For queries about your actual project work, you are encouraged to ask +for advice or help on the IRC channel or mailing list. Generally the IRC +channel is most suitable for but for involved questions or issues that +require a lot of planning, use the netsurf-dev mailing list. This allows +the entire NetSurf team to help and advise you. + +Sometimes we may ask you to work something out for yourself, not out of +spite or laziness, but to encourage you to learn more for yourself. GSoC +is not just a chance to make money, but a chance for you to learn new +skills and to interact with other ways of developing software. + +How to work +----------- + +In terms of your work environment, we recommend that you have a well-lit +comfortable place to work, and that you isolate it from your normal home +computing environment in the sense that if you normally have hundreds of +IRC channels open, browse tens of websites etc, you try not to during +your "work day" -- we're not saying you can't enjoy yourself, just that +the fewer distractions, the easier you will find it to begin with. + +We recommend that you don't have the television or a talk-radio station +on while working. Music however is fine and often encouraged. + +Repository layout +----------------- + +You will be given a branch space on our Subversion repository. It will +be in /branches/ and you will have total control over that +part of the repository. You are encouraged to make feature branches and +to request that your mentor review and merge them regularly. Ideally you +will make a branch, implement one feature (or one packet of work towards +a feature) and get it reviewed and merged. Then make a new branch and +work on the next bit. + +This sounds a little long-winded, but it means that we don't get huge +merge jobs at the end of GSoC, but still fulfils the requirements that +we have to provide to Google your work so that they can see that you +didn't cheat them out of their money. + +You are encouraged to commit early and often to your branch. Changes you +make will be sent to the public commits list, so be sensible in your +commit logs. Regular smaller commits will allow the team to review your +code in-flight and suggest improvements or ideas which might mean you +waste less time writing something which ultimately isn't suitable. + -- cgit v1.2.3