-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Thanks for taking the time to complete this application!
A few general notes:
Before working on your proposal, be sure to read through instructions first!
We will not tolerate plagiarism of any kind. Please write your proposal in your own words. If we find that you have plagiarized application content, we will reject your application without review.
To be considered, a GSoC application must have a written proposal submitted to https://summerofcode.withgoogle.com/. The purpose of creating this issue is to allow stdlib mentors to provide feedback and answer any questions you have regarding your prospective project proposal. Note, however, that we will not write your proposal for you. You, and you alone, are responsible for writing, and the timely submission of, your project proposal.
Please use a succinct name to describe your proposal. This issue should use the following issue naming convention:
[RFC]: the succinct name describing your proposal
For example,
[RFC]: improve tiling algorithms for element-wise ndarray iteration
[RFC]: build a developer dashboard for tracking repository build status
In your proposal, you should include the following information, as described below.
Short biography
*
Please provide a brief overview of your background, including any education/professional qualifications (e.g., university degrees, certificates, etc), technical competencies (e.g., C/C++, JavaScript, CI/CD), and general interests (e.g., high-performance numerical computing, machine learning, frontend development).
Editor
*
What is your preferred code editor (e.g., VSCode, Sublime Text, Vim, Emacs, etc) and why?
Programming experience
*
What is your experience programming? Tell us about something that you've created!
JavaScript experience
*
What is your experience with JavaScript? What is your favorite feature of JavaScript? What is your least favorite feature of JavaScript?
Node.js experience
*
What is your experience with Node.js?
C/Fortran experience
*
What is your experience with C and/or Fortran?
Interest in stdlib
*
What interests you about stdlib? Do you have a favorite feature or example? If so, tell us more!
Contributions to stdlib
*
Please provide a brief summary of your contributions to stdlib thus far, including any unmerged work. This should be a list of pull requests and an indication as to whether each pull request is merged, closed, or still open. If you made significant contributions outside of your pull requests (e.g., reviewing someone else's pull request), you may list that as well.
stdlib showcase
*
Please provide a brief summary of how you've used stdlib and explored its functionality. This should be a list of one or more repositories in which you've created demos, tutorials, how-to guides, and/or showcases using stdlib. Please do not include forks of the main stdlib repository or forks of other someone else's demos in an attempt to pass them off as your own. Any showcases should be your own original work.
Project Description
Tell us about your proposal!
When detailing the project schedule, you are advised to note where along the way you could formulate a pull request. Ideally, pull requests should be points where you can have self-contained, well-documented, and tested pieces of functionality. Breaking the project into smaller sub-tasks which can be completed as part of one or more pull requests helps to keep branch merges and code reviews reasonable. A large code dump at the end of the program will likely be hard to review and merge before the project deadline.
Please do not copy verbatim text from the list of project ideas or from other people's discussions about your project. Always write your proposal in your own words.
If you include any significant text or code from another source in your application, you must properly cite the included material. All papers or references that you use or plan to use must be cited. Place all citations in a "References" section at the bottom of each appliable application section. Copying text without citation is plagarism and will result in your application being rejected.
For an example of a well-written and clearly articulated GSoC proposal, see Aaron Meurer's 2009 SymPy GSoC proposal.
Goals
*
What do you hope to achieve? This should be your project abstract and include a detailed description of the proposed work.
Why this project?
*
What excites you about the proposed project and why?
Qualifications
*
What qualifications do you have to execute on your proposal? How are you suited to work on this project? For example, if you are interested in implementing statistical hypothesis tests, what courses have you taken or books have you read on statistics?
Prior art
*
How have other people achieved the aims of this project? Has the project been implemented before (e.g., in another programming language or library)? Are there are papers or blog posts about it? (hint: this is likely!)
Commitment
*
How much time do you plan to invest in the project before, during, and after the Google Summer of Code program? E.g., for part-time contributors, we expect ~15 hr/week during GSoC based on a 12 week schedule, but we request that you be explicit in your commitment. If you have other commitments, such as if you plan on taking any vacations or time away, have other jobs, or will be busy with exams during the program, let us know about it here.
Schedule
*
Please provide a weekly schedule of how your time will be spent on the subtasks of the project throughout the GSoC program and the expected deliverables. While this is only preliminary and can be adjusted later, if need be, providing such a schedule will help us monitor your progress throughout the program. During your project, understand that you will issue weekly progress reports against the proposed schedule. If you aim to perform any prepwork prior to week 1 (e.g., during the community bonding period), be sure to include that in your answer below. The template below assumes a 12 week schedule. If you are doing an alternate schedule, you can adjust the template accordingly.
Assuming a 12 week schedule,
-
Community Bonding Period:
-
Week 1:
-
Week 2:
-
Week 3:
-
Week 4:
-
Week 5:
-
Week 6: (midterm)
-
Week 7:
-
Week 8:
-
Week 9:
-
Week 10:
-
Week 11:
-
Week 12:
-
Final Week:
Notes:
- The community bonding period is a 3 week period built into GSoC to help you get to know the project community and participate in project discussion. This is an opportunity for you to setup your local development environment, learn how the project's source control works, refine your project plan, read any necessary documentation, and otherwise prepare to execute on your project project proposal.
- Usually, even week 1 deliverables include some code.
- By week 6, you need enough done at this point for your mentor to evaluate your progress and pass you. Usually, you want to be a bit more than halfway done.
- By week 11, you may want to "code freeze" and focus on completing any tests and/or documentation.
- During the final week, you'll be submitting your project.
Related issues
Does this proposal have any related issues (e.g., a proposal idea issue or upstream issues in the main stdlib project or website repositories)? If so, please link to those issues below.