11 | | The second new change is in how projects will be ranked by the community. Up until now, the community ranked student proposals by awarding a score, and we recommended to Google to select all those proposals which matched a single mentor to a single student based on the top of the score ranking. Unfortunately, this process has led to some disappointments for both student and mentor especially where the student was far better at writing proposals than writing code, and we also worry that the old system discriminates against non-native English speakers. As of this year, we therefore request a new part to student proposal ideas, that being of an exam or test the students interested in that proposal can take to demonstrate their programming capability. In 2015, student proposals with accompanying ability test scores for that candidate '''will be preferentially ranked above proposals without test scores'''. |
| 11 | ==== How we are implementing '''student programming aptitude testing''' in 2015 ==== |
| 12 | The second new change is in how projects will be ranked by the community. Up until now, the community ranked student proposals by awarding a score to their written proposal, and we recommended to Google to select all those proposals which matched a single mentor to a single student based on the top of that score ranking. Unfortunately, this process has led to some disappointments for both student and mentor especially where the student was far better at writing proposal texts than writing code, and we also worry that the old system discriminates against non-native English speakers. As of this year, we therefore request a new part to student proposal ideas ''whether proposed by student or mentor'', that being of an exam or test the students interested in that proposal can take to demonstrate their programming capability. In 2015, student proposals with accompanying ability test scores for that candidate '''will be preferentially ranked above proposals without test scores'''. If the precanned proposal from this ideas page or from preceding years written by a mentor lacks a programming test, or the student fails to supply answers to a test, their proposal will not be preferentially ranked no matter its otherwise quality or merit. |
15 | | The scoring by the community will work as before, but preferentially ranked candidates and proposals will be entirely consumed before unpreferentially ranked candidates and proposals, even if the candidate's exam results were poor (though note that in this case no mentor may wish to mentor such a student, and we shall have to exclude such a candidate as a result). |
| 16 | '''Let us be very clear here: if you propose your own project idea and haven't prearranged a mentor on the developer's mailing list, your proposal will NOT be preferentially ranked.''' To prearrange a mentor you almost certainly need to supply lengthy and substantial (> 1,000 lines) examples of C++ libraries you have already written. |
| 17 | |
| 18 | The scoring by the community will work as before based on the community voting on proposals, but preferentially ranked candidates and proposals '''will be entirely consumed''' before unpreferentially ranked candidates and proposals, even if the candidate's exam results were poor (though note that in this case no mentor may wish to mentor such a student, and we shall have to exclude such a candidate as a result). |
| 41 | == INSTRUCTIONS FOR ADDING PRECANNED PROPOSALS == |
| 42 | |
| 43 | Please follow the following proposal structure. See the concurrent hash tables proposal below for an example. |
| 44 | |
| 45 | === No. Title === |
| 46 | Potential mentors: names |
| 47 | |
| 48 | ==== Background ==== |
| 49 | Explanation of proposal background, history etc with hyperlinks. |
| 50 | |
| 51 | ==== GSoC project proposal ==== |
| 52 | Bullet points of items to complete for the GSoC. |
| 53 | |
| 54 | ==== Potential project extension funded by Boost ==== |
| 55 | Not as much detail as the GSoC proposal itself, but enough detail that such an extension could be specced out. |
| 56 | |
| 57 | If there is no good extension, simply say N/A here. |
| 58 | |
| 59 | ==== Programming competency test ==== |
| 60 | Some code for them to write to prove they can program sufficiently. Ideally it should be a small part of the proposal itself modifying real Boost library code, but there is nothing wrong with an actual exam paper, except that maybe they might cheat if you give them too much time and flexibility in when to do it, so if setting an exam question make sure you say here it will be written and set to interested students on some date after GSoC applications close and they'll get X days to finish it. |
| 61 | |
| 62 | How they submit their results is up to you. They can append them to their project proposal, or provide a gist, or email them to you for marking, or whatever. |
| 63 | |
| 64 | If there is no programming competency test, please add your proposal to the second section below the special section for proposals without competency testing. |
| 65 | |
| 66 | |
45 | | Strangely enough, Boost does not provide an implementation of thread safe concurrent associative sets and maps despite that the unordered implementation from Intel's Thread Building Blocks and Microsoft's Parallel Patterns Library was proposed for standardisation in [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3425.html N3425 Concurrent Unordered Associative Containers for C++]. This is probably because that implementation (the split ordered list algorithm by Shalev and Shavit, 2006) had the serious shortcoming of not being thread safe for some operations, most importantly item deletion, and the workarounds proposed by N3425 did not appeal. Moreover, [https://www.usenix.org/legacy/event/atc11/tech/final_files/Triplett.pdf there are other concurrent hash table algorithms which do not have such shortcomings]. |
| 74 | Strangely enough, Boost does not provide an implementation of thread safe concurrent associative sets and maps despite that the unordered implementation from Intel's Thread Building Blocks and Microsoft's Parallel Patterns Library was proposed some years ago for standardisation in [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3425.html N3425 Concurrent Unordered Associative Containers for C++]. This is probably because that implementation (the split ordered list algorithm by Shalev and Shavit, 2006) had the serious shortcoming of not being thread safe for some operations, most importantly item deletion, and the workarounds proposed by N3425 did not appeal. Moreover, [https://www.usenix.org/legacy/event/atc11/tech/final_files/Triplett.pdf there are other concurrent hash table algorithms which do not have such shortcomings]. |