├── .editorconfig
├── .gitattributes
├── .github
├── ISSUE_TEMPLATE
│ ├── application.yml
│ ├── config.yml
│ ├── idea.yml
│ └── weekly_standup.md
├── PULL_REQUEST_TEMPLATE.md
└── workflows
│ ├── ideas_list.yml
│ ├── scripts
│ └── update_ideas_list.js
│ └── weekly_standup.yml
├── .gitignore
├── .npmrc
├── FAQ.md
├── NOTICE
├── README.md
├── ideas.md
├── mentors.md
├── organization
├── README.md
├── applications
│ ├── 2023.md
│ ├── 2024.md
│ ├── 2025.md
│ └── logo.png
├── scripts
│ ├── acceptance_emails.js
│ ├── announcement.js
│ ├── parse_csv.js
│ └── rejection_emails.js
├── slot_announcement_checklist.md
└── templates
│ ├── acceptance.md
│ ├── announcement.md
│ └── rejection.md
└── package.json
/.editorconfig:
--------------------------------------------------------------------------------
1 | #/
2 | # @license Apache-2.0
3 | #
4 | # Copyright (c) 2023 The Stdlib Authors.
5 | #
6 | # Licensed under the Apache License, Version 2.0 (the "License");
7 | # you may not use this file except in compliance with the License.
8 | # You may obtain a copy of the License at
9 | #
10 | # http://www.apache.org/licenses/LICENSE-2.0
11 | #
12 | # Unless required by applicable law or agreed to in writing, software
13 | # distributed under the License is distributed on an "AS IS" BASIS,
14 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | # See the License for the specific language governing permissions and
16 | # limitations under the License.
17 | #/
18 |
19 | # EditorConfig configuration file (see ).
20 |
21 | # Indicate that this file is a root-level configuration file:
22 | root = true
23 |
24 | # Set properties for all files:
25 | [*]
26 | end_of_line = lf
27 | charset = utf-8
28 | trim_trailing_whitespace = true
29 | insert_final_newline = true
30 |
31 | # Set properties for JavaScript files:
32 | [*.{js,js.txt}]
33 | indent_style = tab
34 |
35 | # Set properties for JavaScript ES module files:
36 | [*.{mjs,mjs.txt}]
37 | indent_style = tab
38 |
39 | # Set properties for JavaScript CommonJS files:
40 | [*.{cjs,cjs.txt}]
41 | indent_style = tab
42 |
43 | # Set properties for JSON files:
44 | [*.{json,json.txt}]
45 | indent_style = space
46 | indent_size = 2
47 |
48 | # Set properties for `cli_opts.json` files:
49 | [cli_opts.json]
50 | indent_style = tab
51 |
52 | # Set properties for TypeScript files:
53 | [*.ts]
54 | indent_style = tab
55 |
56 | # Set properties for Python files:
57 | [*.{py,py.txt}]
58 | indent_style = space
59 | indent_size = 4
60 |
61 | # Set properties for Julia files:
62 | [*.{jl,jl.txt}]
63 | indent_style = tab
64 |
65 | # Set properties for R files:
66 | [*.{R,R.txt}]
67 | indent_style = tab
68 |
69 | # Set properties for C files:
70 | [*.{c,c.txt}]
71 | indent_style = tab
72 |
73 | # Set properties for C header files:
74 | [*.{h,h.txt}]
75 | indent_style = tab
76 |
77 | # Set properties for C++ files:
78 | [*.{cpp,cpp.txt}]
79 | indent_style = tab
80 |
81 | # Set properties for C++ header files:
82 | [*.{hpp,hpp.txt}]
83 | indent_style = tab
84 |
85 | # Set properties for Fortran files:
86 | [*.{f,f.txt}]
87 | indent_style = space
88 | indent_size = 2
89 | insert_final_newline = false
90 |
91 | # Set properties for shell files:
92 | [*.{sh,sh.txt}]
93 | indent_style = tab
94 |
95 | # Set properties for AWK files:
96 | [*.{awk,awk.txt}]
97 | indent_style = tab
98 |
99 | # Set properties for HTML files:
100 | [*.{html,html.txt}]
101 | indent_style = tab
102 | tab_width = 2
103 |
104 | # Set properties for XML files:
105 | [*.{xml,xml.txt}]
106 | indent_style = tab
107 | tab_width = 2
108 |
109 | # Set properties for CSS files:
110 | [*.{css,css.txt}]
111 | indent_style = tab
112 |
113 | # Set properties for Makefiles:
114 | [Makefile]
115 | indent_style = tab
116 |
117 | [*.{mk,mk.txt}]
118 | indent_style = tab
119 |
120 | # Set properties for Markdown files:
121 | [*.{md,md.txt}]
122 | indent_style = space
123 | indent_size = 4
124 | trim_trailing_whitespace = false
125 |
126 | # Set properties for `usage.txt` files:
127 | [usage.txt]
128 | indent_style = space
129 | indent_size = 2
130 |
131 | # Set properties for `repl.txt` files:
132 | [repl.txt]
133 | indent_style = space
134 | indent_size = 4
135 |
136 | # Set properties for `package.json` files:
137 | [package.{json,json.txt}]
138 | indent_style = space
139 | indent_size = 2
140 |
141 | # Set properties for `datapackage.json` files:
142 | [datapackage.json]
143 | indent_style = space
144 | indent_size = 2
145 |
146 | # Set properties for `manifest.json` files:
147 | [manifest.json]
148 | indent_style = space
149 | indent_size = 2
150 |
151 | # Set properties for `tslint.json` files:
152 | [tslint.json]
153 | indent_style = space
154 | indent_size = 2
155 |
156 | # Set properties for `tsconfig.json` files:
157 | [tsconfig.json]
158 | indent_style = space
159 | indent_size = 2
160 |
161 | # Set properties for LaTeX files:
162 | [*.{tex,tex.txt}]
163 | indent_style = tab
164 |
165 | # Set properties for LaTeX Bibliography files:
166 | [*.{bib,bib.txt}]
167 | indent_style = tab
168 |
169 | # Set properties for YAML files:
170 | [*.{yml,yml.txt}]
171 | indent_style = space
172 | indent_size = 2
173 |
174 | # Set properties for GYP files:
175 | [binding.gyp]
176 | indent_style = space
177 | indent_size = 2
178 |
179 | [*.gypi]
180 | indent_style = space
181 | indent_size = 2
182 |
--------------------------------------------------------------------------------
/.gitattributes:
--------------------------------------------------------------------------------
1 | #/
2 | # @license Apache-2.0
3 | #
4 | # Copyright (c) 2023 The Stdlib Authors.
5 | #
6 | # Licensed under the Apache License, Version 2.0 (the "License");
7 | # you may not use this file except in compliance with the License.
8 | # You may obtain a copy of the License at
9 | #
10 | # http://www.apache.org/licenses/LICENSE-2.0
11 | #
12 | # Unless required by applicable law or agreed to in writing, software
13 | # distributed under the License is distributed on an "AS IS" BASIS,
14 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | # See the License for the specific language governing permissions and
16 | # limitations under the License.
17 | #/
18 |
19 | # Configuration file which assigns attributes to pathnames.
20 | #
21 | # [1]: https://git-scm.com/docs/gitattributes
22 |
23 | # Automatically normalize the line endings of any committed text files:
24 | * text=auto
25 |
26 | # Override line endings for certain files on checkout:
27 | *.crlf.csv text eol=crlf
28 |
29 | # Denote that certain files are binary and should not be modified:
30 | *.png binary
31 | *.jpg binary
32 | *.jpeg binary
33 | *.gif binary
34 | *.ico binary
35 | *.gz binary
36 | *.zip binary
37 | *.7z binary
38 | *.mp3 binary
39 | *.mp4 binary
40 | *.mov binary
41 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/application.yml:
--------------------------------------------------------------------------------
1 | #/
2 | # @license Apache-2.0
3 | #
4 | # Copyright (c) 2023 The Stdlib Authors.
5 | #
6 | # Licensed under the Apache License, Version 2.0 (the "License");
7 | # you may not use this file except in compliance with the License.
8 | # You may obtain a copy of the License at
9 | #
10 | # http://www.apache.org/licenses/LICENSE-2.0
11 | #
12 | # Unless required by applicable law or agreed to in writing, software
13 | # distributed under the License is distributed on an "AS IS" BASIS,
14 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | # See the License for the specific language governing permissions and
16 | # limitations under the License.
17 | #/
18 |
19 | name: 🚀 Application
20 | description: I'd like to apply to Google Summer of Code to work on stdlib!
21 | title: "[RFC]: "
22 | labels: ["rfc", "2025"]
23 | body:
24 | - type: markdown
25 | attributes:
26 | value: |
27 | Thanks for taking the time to complete this application!
28 |
29 | A few general notes:
30 |
31 | 1. Before working on your proposal, be sure to read through [instructions](https://github.com/stdlib-js/google-summer-of-code/blob/main/README.md) first!
32 |
33 | 1. 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.
34 |
35 | 1. To be considered, a GSoC application **must** have a written proposal submitted to . 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.
36 |
37 | 1. Please use a succinct name to describe your proposal. This issue should use the following issue naming convention:
38 |
39 | - \[RFC]: the succinct name describing your proposal
40 |
41 | For example,
42 |
43 | - \[RFC]: improve tiling algorithms for element-wise ndarray iteration
44 | - \[RFC]: build a developer dashboard for tracking repository build status
45 |
46 | 1. In your proposal, you should include the following information, as described below.
47 |
48 | - type: markdown
49 | attributes:
50 | value: |
51 | * * *
52 | ## Your Background
53 |
54 | We'd like to get to know you and your background!
55 |
56 | - type: input
57 | id: full_name
58 | attributes:
59 | label: Full name
60 | description: What is your full name?
61 | placeholder: e.g., Jane Doe
62 | validations:
63 | required: true
64 |
65 | - type: dropdown
66 | id: enrollment
67 | attributes:
68 | label: University status
69 | description: Are you currently enrolled at a university?
70 | options:
71 | - "Yes"
72 | - "No"
73 | validations:
74 | required: true
75 |
76 | - type: input
77 | id: university
78 | attributes:
79 | label: University name
80 | description: If you are enrolled at a university, what is the name of that university?
81 | validations:
82 | required: false
83 |
84 | - type: input
85 | id: area_of_study
86 | attributes:
87 | label: University program
88 | description: If you are enrolled at a university, what is your area of study?
89 | validations:
90 | required: false
91 |
92 | - type: input
93 | id: expected_graduation
94 | attributes:
95 | label: Expected graduation
96 | description: If you are enrolled at a university, when is your expected graduation date?
97 | validations:
98 | required: false
99 |
100 | - type: textarea
101 | id: bio
102 | attributes:
103 | label: Short biography
104 | description: 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).
105 | validations:
106 | required: true
107 |
108 | - type: input
109 | id: timezone
110 | attributes:
111 | label: Timezone
112 | description: In what timezone are you located?
113 | placeholder: US Pacific Time
114 | validations:
115 | required: true
116 |
117 | - type: input
118 | id: contact
119 | attributes:
120 | label: Contact details
121 | description: How can we contact you? This may include an e-mail address, GitHub username, or other handle. If you have multiple handles/usernames, please list all handles and usernames that you want us to know about in order to help us associate your various usernames with you. Separate each entry with a comma.
122 | placeholder: email:jane@doe.com,github:janedoe123
123 | validations:
124 | required: true
125 |
126 | - type: markdown
127 | attributes:
128 | value: |
129 | * * *
130 |
131 | ## Programming Experience
132 |
133 | Help us understand your programming experience! Don't worry if you are relatively new to programming. Many contributors start fresh, and we can help teach you what you need to know. :smile:
134 |
135 | - type: dropdown
136 | id: tech_platform
137 | attributes:
138 | label: Platform
139 | description: What platform do you use to code?
140 | options:
141 | - Mac
142 | - Linux
143 | - Windows
144 | - Other
145 | validations:
146 | required: true
147 |
148 | - type: textarea
149 | id: tech_editor
150 | attributes:
151 | label: Editor
152 | description: What is your preferred code editor (e.g., VSCode, Sublime Text, Vim, Emacs, etc) and why?
153 | validations:
154 | required: true
155 |
156 | - type: textarea
157 | id: tech_experience
158 | attributes:
159 | label: Programming experience
160 | description: What is your experience programming? Tell us about something that you've created!
161 | validations:
162 | required: true
163 |
164 | - type: textarea
165 | id: tech_javascript
166 | attributes:
167 | label: JavaScript experience
168 | description: What is your experience with JavaScript? What is your favorite feature of JavaScript? What is your least favorite feature of JavaScript?
169 | validations:
170 | required: true
171 |
172 | - type: textarea
173 | id: tech_nodejs
174 | attributes:
175 | label: Node.js experience
176 | description: What is your experience with Node.js?
177 | validations:
178 | required: true
179 |
180 | - type: textarea
181 | id: tech_native
182 | attributes:
183 | label: C/Fortran experience
184 | description: What is your experience with C and/or Fortran?
185 | validations:
186 | required: true
187 |
188 | - type: textarea
189 | id: tech_stdlib
190 | attributes:
191 | label: Interest in stdlib
192 | description: What interests you about stdlib? Do you have a favorite feature or example? If so, tell us more!
193 | validations:
194 | required: true
195 |
196 | - type: dropdown
197 | id: tech_git
198 | attributes:
199 | label: Version control
200 | description: Have you ever used Git for version control?
201 | options:
202 | - "Yes"
203 | - "No"
204 | validations:
205 | required: true
206 |
207 | - type: textarea
208 | id: tech_stdlib_contributions
209 | attributes:
210 | label: Contributions to stdlib
211 | description: 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.
212 | validations:
213 | required: true
214 |
215 | - type: textarea
216 | id: tech_stdlib_showcase
217 | attributes:
218 | label: stdlib showcase
219 | description: 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.
220 | validations:
221 | required: true
222 |
223 | - type: markdown
224 | attributes:
225 | value: |
226 | * * *
227 |
228 | ## Project Description
229 |
230 | Tell us about your proposal!
231 |
232 | 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.
233 |
234 | 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.
235 |
236 | 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.
237 |
238 | For an example of a well-written and clearly articulated GSoC proposal, see Aaron Meurer's [2009 SymPy GSoC proposal](https://github.com/sympy/sympy/wiki/GSoC-2009-Application-Aaron-Meurer).
239 |
240 | - type: textarea
241 | id: proposal_goals
242 | attributes:
243 | label: Goals
244 | description: What do you hope to achieve? This should be your project abstract and include a detailed description of the proposed work.
245 | validations:
246 | required: true
247 |
248 | - type: textarea
249 | id: proposal_why
250 | attributes:
251 | label: Why this project?
252 | description: What excites you about the proposed project and why?
253 | validations:
254 | required: true
255 |
256 | - type: textarea
257 | id: proposal_qualifications
258 | attributes:
259 | label: Qualifications
260 | description: 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?
261 | validations:
262 | required: true
263 |
264 | - type: textarea
265 | id: proposal_prior_art
266 | attributes:
267 | label: Prior art
268 | description: "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!)"
269 | validations:
270 | required: true
271 |
272 | - type: textarea
273 | id: proposal_commitment
274 | attributes:
275 | label: Commitment
276 | description: 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.
277 | validations:
278 | required: true
279 |
280 | - type: textarea
281 | id: proposal_schedule
282 | attributes:
283 | label: Schedule
284 | description: 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.
285 | value: |
286 | Assuming a 12 week schedule,
287 |
288 | - **Community Bonding Period**:
289 |
290 | - **Week 1**:
291 |
292 | - **Week 2**:
293 |
294 | - **Week 3**:
295 |
296 | - **Week 4**:
297 |
298 | - **Week 5**:
299 |
300 | - **Week 6**: (midterm)
301 |
302 | - **Week 7**:
303 |
304 | - **Week 8**:
305 |
306 | - **Week 9**:
307 |
308 | - **Week 10**:
309 |
310 | - **Week 11**:
311 |
312 | - **Week 12**:
313 |
314 | - **Final Week**:
315 |
316 | Notes:
317 |
318 | - 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.
319 | - Usually, even week 1 deliverables include some code.
320 | - 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.
321 | - By week 11, you may want to "code freeze" and focus on completing any tests and/or documentation.
322 | - During the final week, you'll be submitting your project.
323 | validations:
324 | required: true
325 |
326 | - type: textarea
327 | id: related_issues
328 | attributes:
329 | label: Related issues
330 | description: 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.
331 | validations:
332 | required: false
333 |
334 | - type: markdown
335 | attributes:
336 | value: |
337 | * * *
338 |
339 | - type: checkboxes
340 | id: checklist
341 | attributes:
342 | label: Checklist
343 | description: Please ensure the following tasks are completed before submitting a project proposal.
344 | options:
345 | - label: I have read and understood the [Code of Conduct](https://github.com/stdlib-js/stdlib/blob/develop/CODE_OF_CONDUCT.md).
346 | required: true
347 | - label: I have read and understood the application materials found in this repository.
348 | required: true
349 | - label: I understand that plagiarism will not be tolerated, and I have authored this application in my own words.
350 | required: true
351 | - label: I have read and understood the [patch requirement](https://github.com/stdlib-js/google-summer-of-code/blob/main/README.md#patch-requirement) which is necessary for my application to be considered for acceptance.
352 | required: true
353 | - label: I have read and understood the [stdlib showcase requirement](https://github.com/stdlib-js/google-summer-of-code/blob/main/README.md#showcase-requirement) which is necessary for my application to be considered for acceptance.
354 | required: true
355 | - label: The issue name begins with `[RFC]:` and succinctly describes your proposal.
356 | required: true
357 | - label: I understand that, in order to apply to be a GSoC contributor, I must submit my final application to **before** the submission deadline.
358 | required: true
359 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/config.yml:
--------------------------------------------------------------------------------
1 | #/
2 | # @license Apache-2.0
3 | #
4 | # Copyright (c) 2023 The Stdlib Authors.
5 | #
6 | # Licensed under the Apache License, Version 2.0 (the "License");
7 | # you may not use this file except in compliance with the License.
8 | # You may obtain a copy of the License at
9 | #
10 | # http://www.apache.org/licenses/LICENSE-2.0
11 | #
12 | # Unless required by applicable law or agreed to in writing, software
13 | # distributed under the License is distributed on an "AS IS" BASIS,
14 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | # See the License for the specific language governing permissions and
16 | # limitations under the License.
17 | #/
18 |
19 | contact_links:
20 | - name: 💬 Question
21 | url: https://gitter.im/stdlib-js/stdlib
22 | about: Got a question we haven't already answered? Ask us on Element! 🤗
23 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/idea.yml:
--------------------------------------------------------------------------------
1 | #/
2 | # @license Apache-2.0
3 | #
4 | # Copyright (c) 2023 The Stdlib Authors.
5 | #
6 | # Licensed under the Apache License, Version 2.0 (the "License");
7 | # you may not use this file except in compliance with the License.
8 | # You may obtain a copy of the License at
9 | #
10 | # http://www.apache.org/licenses/LICENSE-2.0
11 | #
12 | # Unless required by applicable law or agreed to in writing, software
13 | # distributed under the License is distributed on an "AS IS" BASIS,
14 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | # See the License for the specific language governing permissions and
16 | # limitations under the License.
17 | #/
18 |
19 | name: 💡 Idea
20 | description: I have a project idea!
21 | title: "[Idea]: "
22 | labels: ["idea"]
23 | body:
24 | - type: markdown
25 | attributes:
26 | value: |
27 | Thanks for taking the time to propose a new idea!
28 |
29 | A few general notes:
30 |
31 | 1. Before submitting your idea, please be sure to look through the [list of existing ideas](https://github.com/stdlib-js/google-summer-of-code/issues?q=label%3Aidea+) to ensure that your idea has not already been discussed.
32 |
33 | 1. Also, before submitting your idea, please be sure to reach out over the stdlib [Element channel](https://gitter.im/stdlib-js/stdlib) to discuss it with us first. We'll inform you whether the idea has already been implemented, if the idea will entail enough work to last the duration of the GSoC program, if the idea requires too much work to be meaningfully pursued during GSoC, and if the idea is within the scope of stdlib.
34 |
35 | 1. Understand that submitting an idea is **not** sufficient to participate in GSoC. To be considered, a GSoC application **must** have a written proposal submitted to . To begin working on a GSoC application, we **strongly** recommend using the stdlib [application template](https://github.com/stdlib-js/google-summer-of-code/issues/new?assignees=&labels=rfc%2C2023&template=application.yml&title=%5BRFC%5D%3A+).
36 |
37 | 1. Please use a succinct name to describe your idea. This issue should use the following issue naming convention:
38 |
39 | - \[Idea]: the succinct name describing your idea
40 |
41 | For example,
42 |
43 | - \[Idea]: improving the stdlib REPL
44 | - \[Idea]: add SIMD support to loop tiling macros
45 |
46 | 1. When describing your idea, you should include the following information, as described below.
47 |
48 | - type: textarea
49 | id: idea
50 | attributes:
51 | label: Idea
52 | description: Describe your idea (in 2-5 sentences), including the overall goals and any prior art relevant to its achievement (e.g., academic literature, reference implementations, etc).
53 | validations:
54 | required: true
55 |
56 | - type: textarea
57 | id: expected_outcomes
58 | attributes:
59 | label: Expected outcomes
60 | description: What are the expected outcomes if this idea is successfully implemented?
61 | validations:
62 | required: true
63 |
64 | - type: textarea
65 | id: status
66 | attributes:
67 | label: Status
68 | description: What is the current status of the idea in the stdlib community? This should include any previous work done (e.g., as described in issues and pull requests).
69 | validations:
70 | required: true
71 |
72 | - type: textarea
73 | id: involved_software
74 | attributes:
75 | label: Involved software
76 | description: Would your idea require the use of external dependencies? If so, what are those dependencies and why are they necessary to pursue your idea?
77 | validations:
78 | required: true
79 |
80 | - type: dropdown
81 | id: technology
82 | attributes:
83 | multiple: true
84 | label: Technology
85 | description: "What technology is needed to execute on your idea? (select all that apply)"
86 | options:
87 | - "JavaScript"
88 | - "C"
89 | - "Fortran"
90 | - "nodejs"
91 | - "native addons"
92 | - "JSX, React, or similar"
93 | - "HTML/CSS"
94 | validations:
95 | required: true
96 |
97 | - type: textarea
98 | id: other_technology
99 | attributes:
100 | label: Other technology
101 | description: Please include any other technology which was not selected above which is necessary to execute on your idea.
102 | validations:
103 | required: false
104 |
105 | - type: dropdown
106 | id: difficulty
107 | attributes:
108 | label: Difficulty
109 | description: "How difficult is your idea to pursue? (1: beginner, 3: intermediate, 5: advanced)"
110 | options:
111 | - "5"
112 | - "4"
113 | - "3"
114 | - "2"
115 | - "1"
116 | validations:
117 | required: true
118 |
119 | - type: textarea
120 | id: diffulty_justification
121 | attributes:
122 | label: Difficulty justification
123 | description: What factors contribute to the predicted difficulty? (e.g., technical constraints, missing prerequisite functionality, large refactors, platform variability, etc)
124 | validations:
125 | required: true
126 |
127 | - type: textarea
128 | id: prerequisite_knowledge
129 | attributes:
130 | label: Prerequisite knowledge
131 | description: Please describe any prerequisite knowledge or approaches necessary to pursue your idea (e.g., knowledge of statistics and numerical algorithms, mastery of JavaScript and C, previous experience with React, etc)?
132 | validations:
133 | required: true
134 |
135 | - type: dropdown
136 | id: project_length
137 | attributes:
138 | label: Project length
139 | description: Is this idea suitable for a 350 hour GSoC project, 175 hour GSoC project, or 90 hour GSoC project?
140 | options:
141 | - "350"
142 | - "175"
143 | - "90"
144 | validations:
145 | required: true
146 |
147 | - type: markdown
148 | attributes:
149 | value: |
150 | * * *
151 |
152 | - type: checkboxes
153 | id: checklist
154 | attributes:
155 | label: Checklist
156 | description: Please ensure the following tasks are completed before submitting an idea.
157 | options:
158 | - label: I have read and understood the [Code of Conduct](https://github.com/stdlib-js/stdlib/blob/develop/CODE_OF_CONDUCT.md).
159 | required: true
160 | - label: I have read and understood the application materials found in this repository.
161 | required: true
162 | - label: The issue name begins with `[Idea]:` and succinctly describes your idea.
163 | required: true
164 | - label: I understand that, in order to apply to be a GSoC contributor, I must submit my final application to **before** the submission deadline.
165 | required: true
166 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/weekly_standup.md:
--------------------------------------------------------------------------------
1 | ## 🎉 Weekly Standup 🎉
2 |
3 | > An async stand-up to provide status reports on what you've been up to the previous week, what your plan is for the upcoming week, and to request help for things you are working on.
4 |
5 | _Copy and paste the template below, and answer questions as needed!_
6 |
7 | ```md
8 | **🙌 Thanks I'd like to give**
9 |
10 | - helped me out with...
11 |
12 | **✅ Updates from last week**
13 |
14 | - I worked on
15 |
16 | **🔭 My plan for the current week**
17 |
18 | - I plan on working on...
19 |
20 | **🙏 Challenges that I've faced and things I'd like help with**
21 |
22 | - I had a hard time figuring out...
23 |
24 | **🏝️ My availability for next week**
25 |
26 | - I'll be off on
27 |
28 | **💬 Important items for discussion**
29 |
30 | - I have a question about ...
31 | - Can @ comment on issue #NN?
32 | - I opened #NN for discussion.
33 | - I need to discuss...
34 | ```
35 |
36 | ### :dart: Task Status
37 |
38 | Please make sure pull request labels and draft status reflect the current status of your work!
39 |
40 | @gsoc-2025
41 |
--------------------------------------------------------------------------------
/.github/PULL_REQUEST_TEMPLATE.md:
--------------------------------------------------------------------------------
1 |
2 |
3 |
14 |
--------------------------------------------------------------------------------
/.github/workflows/ideas_list.yml:
--------------------------------------------------------------------------------
1 | #/
2 | # @license Apache-2.0
3 | #
4 | # Copyright (c) 2023 The Stdlib Authors.
5 | #
6 | # Licensed under the Apache License, Version 2.0 (the "License");
7 | # you may not use this file except in compliance with the License.
8 | # You may obtain a copy of the License at
9 | #
10 | # http://www.apache.org/licenses/LICENSE-2.0
11 | #
12 | # Unless required by applicable law or agreed to in writing, software
13 | # distributed under the License is distributed on an "AS IS" BASIS,
14 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | # See the License for the specific language governing permissions and
16 | # limitations under the License.
17 | #/
18 |
19 | # Workflow name:
20 | name: ideas_list
21 |
22 | # Workflow triggers:
23 | on:
24 | # Define all the activity types for which we want to update the ideas list:
25 | issues:
26 | types:
27 | - opened
28 | - edited
29 | - closed
30 | - reopened
31 | - labeled
32 | - unlabeled
33 |
34 | # Allow the workflow to be manually run:
35 | workflow_dispatch:
36 |
37 | # Workflow concurrency group:
38 | concurrency:
39 |
40 | # Specify a group name:
41 | group: ${{ github.workflow }}
42 |
43 | # Specify whether to cancel any currently running workflow in the same concurrency group:
44 | cancel-in-progress: true
45 |
46 | # Workflow jobs:
47 | jobs:
48 |
49 | # Define a job for updating our ideas list...
50 | update-file:
51 |
52 | # Define a display name:
53 | name: 'Update file'
54 |
55 | # Define the type of virtual host machine:
56 | runs-on: ubuntu-latest
57 |
58 | # Define the sequence of job steps...
59 | steps:
60 |
61 | # Checkout the repository:
62 | - name: 'Checkout repository'
63 | uses: actions/checkout@v4
64 | with:
65 | # Specify whether to remove untracked files before checking out the repository:
66 | clean: true
67 |
68 | # Limit clone depth to the most recent commit:
69 | fetch-depth: 100
70 |
71 | # Specify whether to download Git-LFS files:
72 | lfs: false
73 | timeout-minutes: 10
74 |
75 | # Configure Git:
76 | - name: 'Configure Git'
77 | run: |
78 | git config --local user.email "noreply@stdlib.io"
79 | git config --local user.name "stdlib-bot"
80 | timeout-minutes: 5
81 |
82 | # Generate file:
83 | - name: 'Generate file'
84 | uses: actions/github-script@v6
85 | with:
86 | script: |
87 | const fs = require( 'fs' );
88 | const path = require( 'path' );
89 | const script = require( '${{ github.workspace }}/.github/workflows/scripts/update_ideas_list.js' );
90 | await script( github, context, core, fs, path, '${{ github.workspace }}' );
91 |
92 | # Push changes:
93 | - name: 'Push changes'
94 | run: |
95 | # Stage all changes:
96 | git add -A
97 |
98 | # Check whether anything actually changed...
99 | if git diff --cached --quiet; then
100 | # If no files were changed, nothing more to do:
101 | exit 0
102 | fi
103 | # Otherwise, commit and push the changes:
104 | git commit -m "feat: update ideas list" && git push
105 | timeout-minutes: 15
106 |
--------------------------------------------------------------------------------
/.github/workflows/scripts/update_ideas_list.js:
--------------------------------------------------------------------------------
1 | /**
2 | * @license Apache-2.0
3 | *
4 | * Copyright (c) 2023 The Stdlib Authors.
5 | *
6 | * Licensed under the Apache License, Version 2.0 (the "License");
7 | * you may not use this file except in compliance with the License.
8 | * You may obtain a copy of the License at
9 | *
10 | * http://www.apache.org/licenses/LICENSE-2.0
11 | *
12 | * Unless required by applicable law or agreed to in writing, software
13 | * distributed under the License is distributed on an "AS IS" BASIS,
14 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | * See the License for the specific language governing permissions and
16 | * limitations under the License.
17 | */
18 |
19 | 'use strict';
20 |
21 | // VARIABLES //
22 |
23 | var QUERY = `query GetIdeaIssues( $owner: String!, $repo: String!, $label: String! ) {
24 | repo: repository( owner: $owner, name: $repo ) {
25 | issues( labels: [ $label ], first: 100, states: [ OPEN ] ) {
26 | nodes {
27 | number
28 | url
29 | title
30 | body
31 | labels( first: 100 ) {
32 | nodes {
33 | name
34 | }
35 | }
36 | }
37 | }
38 | }
39 | }`;
40 |
41 | var HEADING = [
42 | '# Ideas',
43 | '',
44 | '> List of potential project ideas.',
45 | '',
46 | 'Before working on your GSoC application, please review our list of ideas to see if you find a project which excites you. The list of existing ideas is provided to serve as inspiration and to indicate which directions may be good for stdlib.',
47 | '',
48 | 'If you do find an existing idea that you\'d like to pursue, please be sure to contact us in our [Element](https://gitter.im/stdlib-js/stdlib) channel to discuss it first! **Always be sure to ask about these ideas prior to working on application in order to get the latest information about what is already implemented and what exactly must be done.**',
49 | '',
50 | 'Priority, difficulty, technology, and topic area have no bearing on the chances of an idea being accepted. All ideas are equally good, and your chances of being accepted depend solely on the **quality of your application**.',
51 | '',
52 | '**Project Length**',
53 | '',
54 | 'GSoC allows three different project lengths: **90** hours, **175** hours, and **350** hours. Each idea must indicate whether the idea is a better fit for 90, 175, or 350 hours.',
55 | '',
56 | 'In some cases, we may be able to extend a 175 hour project to a 350 hour project by extending the ideas of what can be done. Similarly, in some cases, a 350 hour project can be shortened to a 175 hour project by only implementing part of an idea and leaving the rest for a future project. In either case, if you want to adjust the project length, please be sure to contact us in our [Element](https://gitter.im/stdlib-js/stdlib) channel to discuss it first!',
57 | '',
58 | '## Your Own Idea',
59 | '',
60 | 'If you\'d like to submit your own idea, that is also welcome; just be sure to propose your idea to stdlib mentors first! After reaching out, we\'ll inform you whether the idea has already been implemented, if the idea will entail enough work to last the duration of the GSoC program, if the idea requires too much work to be meaningfully pursued during GSoC, and if the idea is within the scope of stdlib. **Unsolicited, undiscussed ideas are less likely to get accepted.**',
61 | '',
62 | 'The best project for you is the one you are most interested in and knowledgeable about. Excitement and aptitude are two key ingredients of a successful project and help ensure your commitment and ability to see a project through to completion. So if there is something you are especially passionate about and that you believe aligns with the scope and goals of stdlib, we\'d be happy to hear your pitch!',
63 | '',
64 | 'After discussing with us in our [Element](https://gitter.im/stdlib-js/stdlib) channel and receiving approval to submit your idea, please open an [issue](https://github.com/stdlib-js/google-summer-of-code/issues/new?assignees=&labels=idea&template=idea.yml&title=%5BIdea%5D%3A+) which describes your idea using the [**idea issue template**](https://github.com/stdlib-js/google-summer-of-code/issues/new?assignees=&labels=idea&template=idea.yml&title=%5BIdea%5D%3A+).',
65 | '',
66 | '## Mentors',
67 | '',
68 | 'To learn who might mentor one of the projects listed below, consult the list of potential project [mentors](https://github.com/stdlib-js/google-summer-of-code/blob/main/mentors.md). For each mentor, the list includes a mentor\'s preferred project(s) and/or general interest area.',
69 | '',
70 | '* * *',
71 | '',
72 | ''
73 | ].join( '\n' );
74 |
75 | var OUT_FILENAME = 'ideas.md';
76 |
77 | var FOPTS = {
78 | 'encoding': 'utf8'
79 | };
80 |
81 | var RE_CHECKLIST = /### Checklist[\s\S]*/;
82 |
83 |
84 | // MAIN //
85 |
86 | /**
87 | * Updates the list of project ideas.
88 | *
89 | * @private
90 | * @param {Object} github - pre-authenticated octokit rest client
91 | * @param {Object} context - workflow run context
92 | * @param {Object} core - core action functions
93 | * @param {Object} fs - filesystem APIs
94 | * @param {Object} path - utilities for manipulating filesystem paths
95 | * @param {string} dir - path to the root directory of the repository
96 | * @returns {Promise} promise which returns query results upon resolving
97 | */
98 | async function main( github, context, core, fs, path, dir ) {
99 | var variables;
100 | var results;
101 | var content;
102 | var issues;
103 | var fpath;
104 | var body;
105 | var str;
106 | var t;
107 | var i;
108 |
109 | // Retrieve the list of "idea" issues:
110 | variables = {
111 | 'owner': context.repo.owner,
112 | 'repo': context.repo.repo,
113 | 'label': 'idea'
114 | };
115 | results = await github.graphql( QUERY, variables );
116 |
117 | // Generate content for the ideas file...
118 | issues = results.repo.issues.nodes;
119 | content = [];
120 | for ( i = 0; i < issues.length; i++ ) {
121 | t = issues[ i ].title;
122 | t = t.replace( '[Idea]: ', '' );
123 | t = t[ 0 ].toUpperCase() + t.substring( 1 );
124 |
125 | body = issues[ i ].body.replace( RE_CHECKLIST, '' ).trim();
126 | str = [
127 | '## ' + t,
128 | '',
129 | 'Linked issue: <' + issues[ i ].url + '>',
130 | '',
131 | body
132 | ].join( '\n' );
133 | content.push( str );
134 | }
135 | content = content.join( '\n\n* * *\n\n' );
136 |
137 | // Resolve the output file path:
138 | fpath = path.join( dir, OUT_FILENAME );
139 |
140 | // Create/overwrite the output file:
141 | fs.writeFileSync( fpath, HEADING+content, FOPTS );
142 | }
143 |
144 |
145 | // EXPORTS //
146 |
147 | module.exports = main;
148 |
--------------------------------------------------------------------------------
/.github/workflows/weekly_standup.yml:
--------------------------------------------------------------------------------
1 | #/
2 | # @license Apache-2.0
3 | #
4 | # Copyright (c) 2025 The Stdlib Authors.
5 | #
6 | # Licensed under the Apache License, Version 2.0 (the "License");
7 | # you may not use this file except in compliance with the License.
8 | # You may obtain a copy of the License at
9 | #
10 | # http://www.apache.org/licenses/LICENSE-2.0
11 | #
12 | # Unless required by applicable law or agreed to in writing, software
13 | # distributed under the License is distributed on an "AS IS" BASIS,
14 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | # See the License for the specific language governing permissions and
16 | # limitations under the License.
17 | #/
18 |
19 | # Workflow name:
20 | name: weekly_standup
21 |
22 | # Workflow triggers:
23 | on:
24 | # Run this workflow weekly:
25 | schedule:
26 | # cron: ' '
27 | - cron: '0 0 * * 1'
28 |
29 | # Allow the workflow to be manually run:
30 | workflow_dispatch:
31 |
32 | # Workflow jobs:
33 | jobs:
34 |
35 | # Define a job for creating a weekly standup...
36 | weekly_standup:
37 |
38 | # Define a display name:
39 | name: 'Weekly Standup'
40 |
41 | # Define the type of virtual host machine on which to run the job:
42 | runs-on: ubuntu-latest
43 |
44 | # Define the sequence of job steps...
45 | steps:
46 | # Get the current date:
47 | - name: "Resolve current date"
48 | id: date
49 | run: |
50 | echo "current_date=$(date +'%Y-%m-%d')" >> $GITHUB_OUTPUT
51 |
52 | # Checkout the repository:
53 | - name: 'Checkout repository'
54 |
55 | # Version 4.0
56 | uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac
57 | timeout-minutes: 10
58 |
59 | # Create an issue:
60 | - name: 'Create issue'
61 |
62 | # Version 4.0.1
63 | uses: peter-evans/create-issue-from-file@d60bea1e77c1b5c523216f7c31493883d76ffad7
64 | with:
65 | title: Weekly Standup (${{ steps.date.outputs.current_date}})
66 | content-filepath: ./.github/ISSUE_TEMPLATE/weekly_standup.md
67 | labels: |
68 | weekly standup
69 | assignees: |
70 | kgryte
71 | aayush0325
72 | headlessNode
73 | anandkaranubc
74 | ShabiShett07
75 | gururaj1512
76 |
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | #/
2 | # @license Apache-2.0
3 | #
4 | # Copyright (c) 2023 The Stdlib Authors.
5 | #
6 | # Licensed under the Apache License, Version 2.0 (the "License");
7 | # you may not use this file except in compliance with the License.
8 | # You may obtain a copy of the License at
9 | #
10 | # http://www.apache.org/licenses/LICENSE-2.0
11 | #
12 | # Unless required by applicable law or agreed to in writing, software
13 | # distributed under the License is distributed on an "AS IS" BASIS,
14 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | # See the License for the specific language governing permissions and
16 | # limitations under the License.
17 | #/
18 |
19 | # Files #
20 | #########
21 |
22 |
23 | # Directories #
24 | ###############
25 | build/
26 | downloads/
27 | reports/
28 | tmp/
29 |
30 | # Compiled source #
31 | ###################
32 | *.com
33 | *.class
34 | *.dll
35 | *.o
36 | *.so
37 | *.slo
38 | *.lo
39 | *.obj
40 | *.dylib
41 | *.lai
42 | *.la
43 | *.a
44 | *.lib
45 | *.ko
46 | *.elf
47 | *.node
48 |
49 | # Precompiled headers #
50 | #######################
51 | *.gch
52 | *.pch
53 |
54 | # Executables #
55 | ###############
56 | *.exe
57 | *.out
58 | *.app
59 |
60 | # Packages #
61 | ############
62 | # It is better to unpack these files and commit the raw source
63 | # git has its own built in compression methods
64 | *.7z
65 | *.dmg
66 | *.gz
67 | *.iso
68 | *.jar
69 | *.rar
70 | *.tar
71 | *.zip
72 |
73 | # Logs and databases #
74 | ######################
75 | *.log
76 | *.sql
77 | *.sqlite
78 |
79 | # OS generated files #
80 | ######################
81 | .DS_Store
82 | .DS_Store?
83 | ._*
84 | .Spotlight-V100
85 | .Trashes
86 | Icon?
87 | ehthumbs.db
88 | Thumbs.db
89 | Desktop.ini
90 |
91 | # Temporary files #
92 | ###################
93 | *~
94 |
95 | # Node.js #
96 | ###########
97 | /node_modules/
98 | pids
99 | *.pid
100 | *.seed
101 |
102 | # Typescript #
103 | ##############
104 | *.tsbuildinfo
105 |
106 | # Matlab #
107 | ##########
108 | *.asv
109 | *.mex*
110 |
111 | # Fortran #
112 | ###########
113 | *.mod
114 |
115 | # R #
116 | #####
117 | .Rhistory
118 | .Rapp.history
119 | .Rproj.user/
120 |
121 | # Python #
122 | ##########
123 | __pycache__/
124 | *.py[cod]
125 | *$py.class
126 | *.egg-info/
127 |
128 | # TeX #
129 | #######
130 | *.aux
131 | *.lof
132 | *.log
133 | *.lot
134 | *.fls
135 | *.out
136 | *.toc
137 | *.dvi
138 | *-converted-to.*
139 | *.bbl
140 | *.bcf
141 | *.blg
142 | *-blx.aux
143 | *-blx.bib
144 | *.brf
145 | *.run.xml
146 | *.fdb_latexmk
147 | *.synctex
148 | *.synctex.gz
149 | *.synctex.gz(busy)
150 | *.pdfsync
151 | *.alg
152 | *.loa
153 | acs-*.bib
154 | *.thm
155 | *.nav
156 | *.snm
157 | *.vrb
158 | *.acn
159 | *.acr
160 | *.glg
161 | *.glo
162 | *.gls
163 | *-concordance.tex
164 | *.tikz
165 | *-tikzDictionary
166 | *.idx
167 | *.ilg
168 | *.ind
169 | *.ist
170 |
171 | # Visual Studio #
172 | #################
173 | .vscode/
174 | jsconfig.json
175 |
176 | # Sublime Text #
177 | ################
178 | *.sublime-workspace
179 | *.sublime-project
180 |
--------------------------------------------------------------------------------
/.npmrc:
--------------------------------------------------------------------------------
1 | #/
2 | # @license Apache-2.0
3 | #
4 | # Copyright (c) 2024 The Stdlib Authors.
5 | #
6 | # Licensed under the Apache License, Version 2.0 (the "License");
7 | # you may not use this file except in compliance with the License.
8 | # You may obtain a copy of the License at
9 | #
10 | # http://www.apache.org/licenses/LICENSE-2.0
11 | #
12 | # Unless required by applicable law or agreed to in writing, software
13 | # distributed under the License is distributed on an "AS IS" BASIS,
14 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | # See the License for the specific language governing permissions and
16 | # limitations under the License.
17 | #/
18 |
19 | # Configuration for [npm][1].
20 | #
21 | # [1]: https://docs.npmjs.com/files/npmrc
22 |
23 | # Disable the creation of a lock file:
24 | package-lock = false
25 | shrinkwrap = false
26 |
27 | # Disable automatically "saving" dependencies on install:
28 | save = false
29 |
30 | # Generate provenance metadata:
31 | provenance = true
32 |
--------------------------------------------------------------------------------
/FAQ.md:
--------------------------------------------------------------------------------
1 |
6 |
7 | # FAQ
8 |
9 | > Frequently asked questions.
10 |
11 | ## Why do you strongly suggest that I submit my application to a public issue tracker?
12 |
13 | The application process follows a similar process to how open source software communities normally operate. Namely, someone has a proposal, engages in discussion with the community and key stakeholders, and opens an RFC to formalize and finalize discussion before actually engaging in the proposed work. Accordingly, having a public application process is an extension of the open source process and ethos. For GSoC, we believe that all members of the stdlib community should have a chance to weigh in on possible proposals, not just core developers, in order to ensure that the project goals align with stakeholder interests. The only way to ensure community review is through a public process.
14 |
15 | We understand, however, the feeling of wanting to be protective of one's idea, especially in what is perceived as a competitive environment, for fear that someone else could swoop in and copy the idea. Setting aside how likely such a threat is, our application process requires that an applicant provide their usernames/handles/name along with their application so that we can associate a particular proposal with a single individual. If individual X proposes A and then individual Y comes along, copies A with some small modifications, and proposes A', we have a public record of who was first and can give priority accordingly.
16 |
17 | In short, given that the intent of GSoC is offering new contributors a pathway into open source, we believe that it's conceptually consistent to embrace a culture of public discussion from the outset, as engaging in public discussion and with the community is something that will have to be done throughout the GSoC program and hopefully beyond.
18 |
19 | ## How can I reach out privately if I need to ask something confidential?
20 |
21 | In general, we prefer open and public communication. However, we recognize that you may have legitimate concerns regarding the sharing of personal information, especially in public forums. If you need to communicate privately, you can e-mail one of the [mentors](https://github.com/stdlib-js/google-summer-of-code/blob/main/mentors.md) directly.
22 |
23 | If you do reach out directly to a mentor, please be **respectful** of their time. If your e-mail is not for confidential purposes (e.g., you're e-mailing to ask if you can do idea X or something similar), mentors are likely to refer you to our public [Element](https://gitter.im/stdlib-js/stdlib) channel.
24 |
25 | ## Why are idea issues locked?
26 |
27 | Idea issues are **not** our desired forum for initial project inquiries and are intended to be a lightweight means for core stdlib developers to write down potential GSoC project ideas. Our aim is to keep idea issues as clear and succinct as possible and to avoid long drawn out discussions which are better suited for chat.
28 |
29 | If you have questions or are interested in pursuing a particular idea, you should reach out in our [Element](https://gitter.im/stdlib-js/stdlib) channel.
30 |
--------------------------------------------------------------------------------
/NOTICE:
--------------------------------------------------------------------------------
1 | Copyright (c) 2023-2025 The Stdlib Authors.
2 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
6 |
7 | # Google Summer of Code
8 |
9 | > Resources for the [Google Summer of Code][gsoc] program.
10 |
11 | Hello! And welcome to stdlib's [Google Summer of Code][gsoc] (GSoC) resource repository.
12 |
13 | GSoC is a global program that offers new contributors (who are **18** years or older) an opportunity to be paid for contributing to an open source project over a three month period. Contributors are paid by Google to work under the guidance of mentors from an open source community. GSoC is a great opportunity to learn, develop new skills, build connections, acquire experience working with a larger and often distributed team, and be financially compensated for your efforts.
14 |
15 | In this repository, you'll find information on how to apply for GSoC and a list of potential ideas which could serve as the basis for a GSoC project.
16 |
17 | ## Time Commitment
18 |
19 | GSoC contributors are [expected][gsoc-faq-time-commitment] to work either **350** hours (full-time equivalent), **175** hours (part-time equivalent), or **90** hours (short-time equivalent) over the course of the program. The default schedule runs over 3 months (12 weeks) and can potentially be spread out over a longer period.
20 |
21 | The program start date is [**non-negotiable**][gsoc-faq-schedule-start]. All GSoC contributors **must** begin the program at the same time.
22 |
23 | ## Application Process
24 |
25 | In order to apply to GSoC with [stdlib][stdlib], you must:
26 |
27 | 1. Read the GSoC [contributor guide][gsoc-contributor-guide].
28 | 1. Read the resources in **this** repository in full.
29 | 1. Visit the main [stdlib project repository][stdlib] and familiarize yourself with the source code, project organization, and general conventions.
30 | 1. Read and understand the [Code of Conduct][stdlib-code-of-conduct].
31 | 1. Consult the project [issue tracker][stdlib-issues] to find ongoing [stdlib][stdlib-issues] discussions.
32 | 1. Read through the project [contributing guide][stdlib-contributing] to learn how to start developing [stdlib][stdlib].
33 | 1. Create a [GitHub account][github-create-account], if you do not already have one.
34 | 1. Submit **at least** one patch to [stdlib][stdlib]. All applications which are not accompanied by at least one patch to stdlib will be **rejected**. Instructions as to how to fulfill the [patch requirement](#patch-requirement) are described below.
35 | 1. Create **at least** one demo, tutorial, how-to guide, and/or showcase using [stdlib][stdlib]. All applications which are not accompanied by at least one example usage will be **rejected**. Instructions on how to fulfill the [showcase requirement](#showcase-requirement) are described below.
36 | 1. Review our [list of ideas][stdlib-gsoc-ideas] to see if you find a project which excites you. If you'd like to submit your own idea, that is fine; just be sure to propose your idea to stdlib mentors first! **Unsolicited, undiscussed ideas are less likely to get accepted.**
37 | 1. Develop your application, making sure to follow the [application template][stdlib-gsoc-application-template]. We strongly suggest opening an [issue][stdlib-gsoc-application-template] which describes your project using the [application issue template][stdlib-gsoc-application-template]. Doing so allows individuals who are not on the [GSoC website][gsoc] to review your application and provide feedback.
38 | 1. **The application deadline is April 8, 18:00 UTC.** You are **strongly** advised to submit your application well in advance of the deadline. Google will **not** accept late applications for any reason. You will be able to edit your application up until the deadline, so, if you have a draft, submit it early and continue to update it as time allows.
39 |
40 | Please remember that all applications **must** go through Google's application system and you **MUST SUBMIT YOUR APPLICATION ON GOOGLE'S WEBSITE**. If you do not submit your application on the [GSoC website][gsoc], we **cannot** accept your application.
41 |
42 | ### Tips
43 |
44 | The intent of GSoC is to provide a way for new contributors to join and participate in the world of open source. The contributors most likely to be selected and ultimately succeed are those who are engaged in the community and hoping to continue their involvement beyond the duration of the GSoC program. In general, for most projects, **being a good community member is more important than being a good coder**.
45 |
46 | **Communicate.** Communication is probably the most important part of the application process. Talk to mentors and other stdlib developers, **listen** when they offer advice, and demonstrate that you've understood their suggestions by incorporating their feedback into what you are proposing. Failure to incorporate feedback **significantly** lowers your chance of success.
47 |
48 | **Read the instructions.** Always read (and re-read) all instructions when submitting proposals. Do not simply submit a resume, scientific paper, presentation, or other file which does not contain any information about the project you'd like to pursue. Failure to follow instructions is guaranteed to lead to proposal rejection.
49 |
50 | **Be professional.** Show respect and demonstrate that you will take the mentoring relationship seriously. That means actively listening when you receive feedback and always valuing the time of each member in the [stdlib][stdlib] community. Poor communication and a failure to read and follow instructions convey a lack of respect and a lack of consideration for mentor time, and no mentor wants to work with a contributor who doesn't exhibit the professionalism necessary to ensure both the success of their project and their personal growth as a [stdlib][stdlib] community member.
51 |
52 | ### Questions
53 |
54 | If you have questions, first check whether the questions have already been answered in the GSoC [FAQ][gsoc-faq]. If you still have a question after consulting the GSoC [FAQ][gsoc-faq], you can reach out on the stdlib [Element][stdlib-gitter] channel.
55 |
56 | You can use [Element][stdlib-gitter] to solicit feedback on initial project ideas and to get help as you start working with the [stdlib][stdlib] codebase. Keep in mind that the more specific and clear your questions on stdlib forums, the more likely you are to get a good answer. An open-ended or vague question is unlikely to get a useful response.
57 |
58 | For example, a good question could be something along the lines of
59 |
60 | > I'm interested in project X, and I've done a bit of research and found that issues Y and Z seem related. Based on my findings, a, b, and c are already implemented, so I'd like to know whether it would be reasonable to propose a project that would achieve d, e, and f.
61 |
62 | In contrast, the following question is too open-ended and too vague to solicit a meaningful response
63 |
64 | > I'm interested in project X. Please help me to work on this.
65 |
66 | When reaching out over [Element][stdlib-gitter], be sure to introduce yourself so that we can get to know you. Some useful pieces of information to include
67 |
68 | - Level of familiarity with JavaScript (including years of programming and previous projects).
69 | - Education level (high school / college / PhD).
70 | - Any particular expertise (e.g., statistics, numerical algorithms).
71 | - Any particular interests (e.g., machine learning, natural language processing, asynchronous JavaScript, user interface design, etc).
72 | - Familiarity with [stdlib][stdlib] (e.g., have you used [stdlib][stdlib]?).
73 | - Other possibly relevant information (e.g., geographical location, native language, etc).
74 |
75 | ### Project Ideas
76 |
77 | Before working on your GSoC application, please review our [list of ideas][stdlib-gsoc-ideas] to see if you find a project which excites you. The list of existing ideas is provided to serve as inspiration and to indicate which directions may be good for [stdlib][stdlib].
78 |
79 | If you do find an existing idea that you'd like to pursue, please be sure to contact us in our [Element][stdlib-gitter] channel to discuss it first! **Always be sure to ask about these ideas prior to working on application in order to get the latest information about what is already implemented and what exactly must be done.**
80 |
81 | The [list of ideas][stdlib-gsoc-ideas] is organized by labels according to the following conventions:
82 |
83 | **Priority**
84 |
85 | - `high`: ideas that are considered important in our roadmap.
86 | - `normal`: ideas that are not urgent but would be nice to have sooner rather than later.
87 | - `low`: ideas that are novel or interesting, but are low on our priority list.
88 |
89 | **Difficulty**
90 |
91 | - `1`: an idea suitable for someone with little to no JavaScript experience.
92 | - `2`: an idea suitable for someone with a working knowledge of JavaScript.
93 | - `3`: an idea that is likely to be challenging but manageable.
94 | - `4`: an idea that is likely to be challenging and has ambitious goals.
95 | - `5`: an idea that is likely to be difficult to implement with several unknowns.
96 |
97 | **Technology**
98 |
99 | - `javascript`: an idea that involves programming in JavaScript. At least some JavaScript is likely to be required for all ideas.
100 | - `nodejs`: an idea that requires developing with Node.js. Working with Node.js is likely to be required for most, if not all, ideas, as Node.js is the default environment for testing, benchmarking, and local development.
101 | - `c`: an idea that involves programming in C. This is required for Node.js native add-ons.
102 | - `fortran`: an idea that involves programming in Fortran. This is required for working on BLAS/LAPACK bindings.
103 | - `html/css`: an idea that involves using HTML and CSS (e.g., if building a frontend application).
104 | - `jsx/react`: an idea that involves programming with React JSX (e.g., if working on the stdlib website).
105 | - `native addons`: an idea that involves developing Node.js native add-ons.
106 | - `typescript`: an idea that involves programming in TypeScript.
107 |
108 | Priority, difficulty, technology, and topic area have no bearing on the chances of an idea being accepted. All ideas are equally good, and your chances of being accepted depend solely on the **quality of your application**.
109 |
110 | **Project Length**
111 |
112 | GSoC allows three different project lengths: **90** hours, **175** hours and **350** hours. Each idea must indicate whether the idea is a better fit for 90, 175, or 350 hours.
113 |
114 | In some cases, we may be able to extend a 175 hour project to a 350 hour project by extending the ideas of what can be done. Similarly, in some cases, a 350 hour project can be shortened to a 175 hour project by only implementing part of an idea and leaving the rest for a future project. In either case, if you want to adjust the project length, please be sure to contact us in our [Element][stdlib-gitter] channel to discuss it first!
115 |
116 | #### Your Own Idea
117 |
118 | If you'd like to submit your own idea, that is also welcome; just be sure to propose your idea to stdlib mentors first! After reaching out, we'll inform you whether the idea has already been implemented, if the idea will entail enough work to last the duration of the GSoC program, if the idea requires too much work to be meaningfully pursued during GSoC, and if the idea is within the scope of stdlib. **Unsolicited, undiscussed ideas are less likely to get accepted.**
119 |
120 | The best project for you is the one you are most interested in and knowledgeable about. Excitement and aptitude are two key ingredients of a successful project and help ensure your commitment and ability to see a project through to completion. So if there is something you are especially passionate about and that you believe aligns with the scope and goals of [stdlib][stdlib], we'd be happy to hear your pitch!
121 |
122 | After discussing with us in our [Element][stdlib-gitter] channel and receiving approval to submit your idea, please open an [issue][stdlib-gsoc-idea-template] which describes your idea using the [**idea issue template**][stdlib-gsoc-idea-template].
123 |
124 | ### Patch Requirement
125 |
126 | In addition to the written proposal, we **require** every [GSoC][gsoc] applicant to write a patch and have it merged into the main [stdlib repository][stdlib].
127 |
128 | > [!IMPORTANT]
129 | > We take your patches to [stdlib][stdlib] into **strong** consideration when reviewing your proposal. Submitting one or more patches is your best opportunity to demonstrate that you are capable of doing what is included in your proposal.
130 |
131 | To submit a patch,
132 |
133 | 1. Fork the [stdlib repository][stdlib].
134 |
135 | 1. Setup your platform to develop [stdlib][stdlib] (e.g., install Git, clone your forked repository, set it up to track the remote upstream [stdlib repository][stdlib], install dependencies, and initialize your local development environment). Our [contributing guide][stdlib-contributing] walks you through setting up Git and details our preferred way of development.
136 |
137 | Please do **not** submit patches through the GitHub web editor. You will need to learn how to use Git and develop [stdlib][stdlib] locally if your project is accepted. Taking the time now to use Git and develop [stdlib][stdlib] locally increases your chance of success and helps you decide whether [stdlib][stdlib] is a good fit for you.
138 |
139 | 1. Find something in [stdlib][stdlib] that doesn't work, needs improvement, or would be a useful addition. If you need inspiration, feel free to fix any issue in the [list of issues][stdlib-issues-good-first] which are good for first time contributors.
140 |
141 | In addition to the issues, search for `FIXME` or `TODO` in the codebase. You can use `grep` from the command-line with `git grep "TODO"`.
142 |
143 | You can also play around in the [stdlib][stdlib] REPL and find something that needs fixing or could be implemented.
144 |
145 | 1. Once you've found something, if an issue doesn't already exist, open an issue on the [stdlib issue tracker][stdlib-issues] describing the problem and your proposed solution.
146 |
147 | If your project will use a language other than JavaScript (e.g., C or Fortran), you should submit patches that use that language, as well, in order to demonstrate that you are proficient in that language.
148 |
149 | Note that your patch **must** be code-related, not documentation. While documentation fixes are always welcome, they do **not** fulfill the patch requirement.
150 |
151 | And further note that your patch does **not** need to be related to your proposed project in order to satisfy the patch requirement. In order to familiarize yourself with the code on which you'd be working, you may wish to try to fix a relevant bug in the same or similar code, but this is **not** part of the patch requirement.
152 |
153 | 1. Publish your patch for peer review by creating a pull request on GitHub. You must submit your pull request through GitHub (as opposed to, for example, pasting a patched file on an issue) as this is the easiest way for us to review your code and provide feedback and is what we expect from a contributor working on a [GSoC][gsoc] project.
154 |
155 | You must submit a patch that is successfully reviewed and merged to satisfy the patch requirement. We do **not** consider applications without successfully merged patches.
156 |
157 | A successful patch demonstrates your technical proficiency and your ability to interact with the [stdlib][stdlib] community.
158 |
159 | 1. Once you've created a pull request on GitHub, [stdlib][stdlib] reviewers will review your code and potentially request changes. You **should** address these changes.
160 |
161 | Throughout the development and feedback process, you should **always** run unit tests locally to verify expected behavior.
162 |
163 | During review, please be patient with reviewers. Due to [GSoC][gsoc], there may be a number of pull requests to review, and we may be slow to review all pull requests, especially if they are submitted close to the application deadline. You are **strongly** encouraged to submit your pull request(s) early on in the application process to give yourself the best chance for having a merged patch before the **application** deadline.
164 |
165 | While having a patch merged before the application deadline is preferred, if your patch is still under review, that is fine. What is critical is that your patch be merged before the **acceptance** deadline.
166 |
167 | It is up to you to respond to our feedback in a timely enough manner in order for your patch to be merged before the **acceptance** deadline.
168 |
169 | 1. **In your application, please provide a brief summary of your contributions to [stdlib][stdlib] thus far, including work which has not yet been merged. 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.
170 |
171 | ### Showcase Requirement
172 |
173 | In addition to the written proposal, we **require** every [GSoC][gsoc] applicant to create a tutorial, how-to guide, and/or showcase demonstrating [stdlib][stdlib] usage.
174 |
175 | > [!TIP]
176 | > The showcase requirement is your opportunity to demonstrate your excitement about stdlib and set yourself apart from other GSoC applicants. And you never know, if you do something really innovative, we might just showcase your showcase and make it a part of the official stdlib documentation!
177 |
178 | To create a showcase,
179 |
180 | 1. Create a new repository on GitHub and give it an appropriate name.
181 |
182 | 1. Setup a local repository on your machine which tracks the remote repository that you created on GitHub.
183 |
184 | ```bash
185 | git remote add origin https://github.com//.git
186 | ```
187 |
188 | where `` is your GitHub user name and `` is the name of the repository you just created on GitHub.
189 |
190 | 1. In your local repository, create a minimal `.gitignore` file with the following contents:
191 |
192 | ```text
193 | /node_modules/
194 | ```
195 |
196 | Alternatively, feel free to copy the `.gitignore` found in [this repository][stdlib-gsoc-gitignore].
197 |
198 | 1. In your local repository, create a minimal `package.json` file with the following contents:
199 |
200 | ```javascript
201 | {
202 | "private": true,
203 | "dependencies": []
204 | }
205 | ```
206 |
207 | 1. Provided you've already locally installed Node.js and have access to a JavaScript package manager (e.g., `npm`, which, by default, is installed as part of most Node.js distributions), run
208 |
209 | ```bash
210 | npm install @stdlib/stdlib --save
211 | ```
212 |
213 | where `npm install` may be replaced by the equivalent command if you prefer other package managers, such as `yarn` or `jspm`.
214 |
215 | After running this command, the package manager should install [stdlib][stdlib] inside a `node_modules` folder at the top-level of the local repository folder, and the package manager should update the `package.json` you created above to include `@stdlib/stdlib` as a dependency.
216 |
217 | 1. Assuming you've locally installed Git, go ahead and create an initial commit with the added files.
218 |
219 | ```bash
220 | git add -A && git commit
221 | ```
222 |
223 | You can use the following commit message:
224 |
225 | ```text
226 | chore: add initial files
227 | ```
228 |
229 | 1. Provided you've setup your local repository to track the corresponding remote repository on GitHub, push your recent commit to GitHub.
230 |
231 | ```bash
232 | git push origin main
233 | ```
234 |
235 | where we assume that `main` is the default branch name. If you use a different default, you should modify the previous command accordingly.
236 |
237 | 1. Once you've completed the above, you are now ready to create your [stdlib][stdlib] showcase! Feel free to create a tutorial, how-to guide, and/or demo application showcasing how one can use stdlib. The showcase should be written in JavaScript, C, and/or TypeScript. **Please do not simply copy an existing example from the [stdlib][stdlib] repository. And please do NOT simply copy-and-paste output from an LLM.** We are interested in seeing your creativity and your willingness to familiarize yourself with the stdlib codebase.
238 |
239 | 1. Once you've implemented your showcase, commit the corresponding source files to your local repository and push to your remote using the Git commands we used above.
240 |
241 | 1. **In your application, please provide a brief summary of your [stdlib][stdlib] showcase. This should be a list of one or more repositories hosted on GitHub demonstrating stdlib usage.**
242 |
243 | > [!CAUTION]
244 | > Please do not (a) simply copy/fork another showcase repository and claim it as your own and (b) ask an LLM to write the entirety of your showcase for you. LLMs are not particularly good at generating stdlib code (at least not yet!), making it fairly easy to detect when someone has simply copy-pasted LLM output. We understand that some may find our requirements burdensome, but we've found that the more a GSoC contributor dives into the stdlib codebase and familiarizes themselves with our conventions and feature set, the more likely that the GSoC contributor will be a great fit for the stdlib community and ultimately succeed in completing their GSoC project.
245 |
246 | ### Plagiarism
247 |
248 | Please note that we will **not** tolerate plagiarism in any form. When developing your application, **do so by writing in your own words**.
249 |
250 | While other applicants may publicly discuss and submit proposals for the same idea, you should not lift content from their proposals. You should write and propose what **you** think is the best course of action for ensuring a successful project according to a timeline which **you** believe is appropriate.
251 |
252 | **If we detect that your application contains plagiarized content, we will reject your application without review.**
253 |
254 | Additionally, while we recognize that, for many contributors, English may not be your first language, please avoid using LLMs (e.g., ChatGPT, etc). We can typically tell when individuals rely on LLMs to auto-generate application content (and code contributions!), and what this signals to us is that you cannot be bothered to take the time to write a thoughtful application and that you likely will not be capable of earning our trust.
255 |
256 | The best candidates are those who are thoughtful, who pay close attention to detail, and who are eager and willing to learn.
257 |
258 | * * *
259 |
260 | ## Attribution
261 |
262 | This document borrows heavily from
263 |
264 | - [Python Software Foundation GSoC guidelines][psf-gsoc]
265 | - [SymPy GSoC guidelines][sympy-gsoc]
266 |
267 | ## License
268 |
269 | This document may be reused under a [Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license][cc-by-sa-4.0].
270 |
271 |
272 |
273 | [gsoc]: https://summerofcode.withgoogle.com/
274 |
275 | [gsoc-contributor-guide]: https://google.github.io/gsocguides/student/
276 |
277 | [gsoc-faq]: https://developers.google.com/open-source/gsoc/faq
278 |
279 | [gsoc-faq-time-commitment]: https://developers.google.com/open-source/gsoc/faq#how_much_time_does_gsoc_participation_take
280 |
281 | [gsoc-faq-schedule-start]: https://developers.google.com/open-source/gsoc/faq#can_the_schedule_be_adjusted_if_my_school_ends_latestarts_early
282 |
283 | [gsoc-timeline]: https://developers.google.com/open-source/gsoc/timeline
284 |
285 | [stdlib]: https://github.com/stdlib-js/stdlib
286 |
287 | [stdlib-issues]: https://github.com/stdlib-js/stdlib/issues
288 |
289 | [stdlib-issues-good-first]: https://github.com/stdlib-js/stdlib/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22
290 |
291 | [stdlib-contributing]: https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md
292 |
293 | [stdlib-code-of-conduct]: https://github.com/stdlib-js/stdlib/blob/develop/CODE_OF_CONDUCT.md
294 |
295 | [stdlib-gsoc-application-template]: https://github.com/stdlib-js/google-summer-of-code/issues/new?assignees=&labels=rfc%2C2023&template=application.yml&title=%5BRFC%5D%3A+
296 |
297 | [stdlib-gsoc-idea-template]: https://github.com/stdlib-js/google-summer-of-code/issues/new?assignees=&labels=idea&template=idea.yml&title=%5BIdea%5D%3A+
298 |
299 | [stdlib-gsoc-ideas]: https://github.com/stdlib-js/google-summer-of-code/labels/idea
300 |
301 | [stdlib-gsoc-gitignore]: https://github.com/stdlib-js/google-summer-of-code/blob/main/.gitignore
302 |
303 | [stdlib-gitter]: https://gitter.im/stdlib-js/stdlib
304 |
305 | [github-create-account]: https://github.com/signup
306 |
307 | [psf-gsoc]: https://python-gsoc.org/contributors.html
308 |
309 | [sympy-gsoc]: https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions
310 |
311 | [cc-by-sa-4.0]: https://creativecommons.org/licenses/by-sa/4.0/
312 |
313 |
314 |
--------------------------------------------------------------------------------
/ideas.md:
--------------------------------------------------------------------------------
1 | # Ideas
2 |
3 | > List of potential project ideas.
4 |
5 | Before working on your GSoC application, please review our list of ideas to see if you find a project which excites you. The list of existing ideas is provided to serve as inspiration and to indicate which directions may be good for stdlib.
6 |
7 | If you do find an existing idea that you'd like to pursue, please be sure to contact us in our [Element](https://gitter.im/stdlib-js/stdlib) channel to discuss it first! **Always be sure to ask about these ideas prior to working on application in order to get the latest information about what is already implemented and what exactly must be done.**
8 |
9 | Priority, difficulty, technology, and topic area have no bearing on the chances of an idea being accepted. All ideas are equally good, and your chances of being accepted depend solely on the **quality of your application**.
10 |
11 | **Project Length**
12 |
13 | GSoC allows three different project lengths: **90** hours, **175** hours, and **350** hours. Each idea must indicate whether the idea is a better fit for 90, 175, or 350 hours.
14 |
15 | In some cases, we may be able to extend a 175 hour project to a 350 hour project by extending the ideas of what can be done. Similarly, in some cases, a 350 hour project can be shortened to a 175 hour project by only implementing part of an idea and leaving the rest for a future project. In either case, if you want to adjust the project length, please be sure to contact us in our [Element](https://gitter.im/stdlib-js/stdlib) channel to discuss it first!
16 |
17 | ## Your Own Idea
18 |
19 | If you'd like to submit your own idea, that is also welcome; just be sure to propose your idea to stdlib mentors first! After reaching out, we'll inform you whether the idea has already been implemented, if the idea will entail enough work to last the duration of the GSoC program, if the idea requires too much work to be meaningfully pursued during GSoC, and if the idea is within the scope of stdlib. **Unsolicited, undiscussed ideas are less likely to get accepted.**
20 |
21 | The best project for you is the one you are most interested in and knowledgeable about. Excitement and aptitude are two key ingredients of a successful project and help ensure your commitment and ability to see a project through to completion. So if there is something you are especially passionate about and that you believe aligns with the scope and goals of stdlib, we'd be happy to hear your pitch!
22 |
23 | After discussing with us in our [Element](https://gitter.im/stdlib-js/stdlib) channel and receiving approval to submit your idea, please open an [issue](https://github.com/stdlib-js/google-summer-of-code/issues/new?assignees=&labels=idea&template=idea.yml&title=%5BIdea%5D%3A+) which describes your idea using the [**idea issue template**](https://github.com/stdlib-js/google-summer-of-code/issues/new?assignees=&labels=idea&template=idea.yml&title=%5BIdea%5D%3A+).
24 |
25 | ## Mentors
26 |
27 | To learn who might mentor one of the projects listed below, consult the list of potential project [mentors](https://github.com/stdlib-js/google-summer-of-code/blob/main/mentors.md). For each mentor, the list includes a mentor's preferred project(s) and/or general interest area.
28 |
29 | * * *
30 |
31 | ## Implement a broader range of statistical distributions
32 |
33 | Linked issue:
34 |
35 | ### Idea
36 |
37 | The goal of this idea is to implement all distributions found in SciPy [stats](https://docs.scipy.org/doc/scipy/reference/stats.html#statsrefmanual). Distribution support will entail implementing APIs for computing PDFs, CDFs, quantiles, and other distribution properties. Additionally, stdlib should support APIs for drawing random variates from any implemented distributions.
38 |
39 | ### Expected Outcomes
40 |
41 | stdlib users will be able to construct, and compute various properties of, every statistical distribution present in SciPy in JavaScript.
42 |
43 | ### Involved Software
44 |
45 | No runtime dependencies should be necessary. SciPy will be necessary in order to provide reference test results.
46 |
47 | ### Prerequisite Knowledge
48 |
49 | JavaScript, Node.js. Familiarity with C/C++/Fortran would help.
50 |
51 | ### Difficulty
52 |
53 | Intermediate. Difficulties may arise for distributions whose properties and moments have complicated formulations. Developing JavaScript implementations will likely require consulting C/C++ and possibly Fortran code.
54 |
55 | ### Project Length
56 |
57 | 350 hours.
58 |
59 | * * *
60 |
61 | ## Provide APIs for computing Fast Fourier Transforms
62 |
63 | Linked issue:
64 |
65 | ### Idea
66 |
67 | The goal of this idea is to expose a set of Fast Fourier Transform (FFT) interfaces similar to those available in NumPy and as documented in the [Data APIs Array API specification](https://data-apis.org/array-api/latest/extensions/fourier_transform_functions.html). Similar to stdlib's BLAS interfaces, we may want to allow switching out the FFT backend.
68 |
69 | One potential reference implementation which could form the basis of this idea is pocketfft, as done in NumPy:
70 |
71 | - https://github.com/mreineck/pocketfft
72 | - https://gitlab.mpcdf.mpg.de/mtr/pocketfft
73 |
74 | ### Expected Outcomes
75 |
76 | stdlib users would be able to evaluate FFT operations on stdlib ndarrays. Ideally, we'd also provide a set of C APIs.
77 |
78 | ### Involved Software
79 |
80 | Will need to consult reference implementations in C/Fortran.
81 |
82 | ### Prerequisite Knowledge
83 |
84 | JavaScript, Node.js, C/C++/Fortran
85 |
86 | ### Difficulty
87 |
88 | Hard. This may be a straightforward port, or it may not be. More R&D is needed.
89 |
90 | ### Project Length
91 |
92 | 350 hours.
93 |
94 | ### Potential Mentors
95 |
96 | @kgryte @Planeshifter @rreusser @Pranavchiku @czgdp1807
97 |
98 | * * *
99 |
100 | ## Developer dashboard for tracking ecosystem build failures
101 |
102 | Linked issue:
103 |
104 | ### Idea
105 |
106 | The [stdlib](https://github.com/stdlib-js/stdlib) project encompasses over 3500 repositories which are orchestrated via a centralized repository. While orchestration largely works as intended, build failures do happen, and quickly detecting and resolving build failures in standalone repositories is critical to prevent downstream breakages and ensure ecosystem integrity.
107 |
108 | The goal of this idea is to build a developer dashboard to display in real-time standalone repository build failures. We currently have the backend database which collects build results in real-time; however, we have yet to build a frontend for viewing and analyzing such data.
109 |
110 | The expected roadmap is as follows:
111 |
112 | - Build a Node.js backend for querying a PostgreSQL database.
113 | - Build a frontend dashboard which interfaces with the backend. As this will be a developer facing application, the choice of technologies is greenfield. Potential options may include ESBuild, tailwind, etc.
114 | - Add support for filtering the dashboard based on build status and other features.
115 | - Allow for quick navigation to repository resources and build artifacts.
116 | - Extend the dashboard to support historical overviews and other drill down metrics.
117 |
118 | ### Expected Outcomes
119 |
120 | stdlib developers will be able to navigate to a webpage and see the build status for all repositories at once.
121 |
122 | ### Involved Software
123 |
124 | This will involve building a frontend application and interfacing with a backend for querying a PostgreSQL database. We may want to try more "cutting edge" technology here, such as ESBuild, tailwind, etc.
125 |
126 | ### Prerequisite Knowledge
127 |
128 | JavaScript, Node.js, CSS, HTML, JSX.
129 |
130 | ### Difficulty
131 |
132 | Intermediate. Requires a fair amount of frontend engineering knowledge and modern frontend application development.
133 |
134 | ### Project Length
135 |
136 | 175/350 hours. A skilled contributor may be able to execute on this faster. If so, scope could be expanded to include analytics and historical overviews.
137 |
138 | ### Potential Mentors
139 |
140 | @kgryte @Planeshifter @steff456
141 |
142 | * * *
143 |
144 | ## Expand support for additional pseudorandom number generators
145 |
146 | Linked issue:
147 |
148 | ### Idea
149 |
150 | The goal of this idea is to implement a variety of PRNGs for use within stdlib to generate pseudorandom numbers. The project currently uses Mersenne Twister as its default PRNG; however, this PRNG, while common, is not ideal given its comparatively large internal state. Would be great to have a collection of PRNGs, such as PCG, Philox, Xorshift, and more.
151 |
152 | ### Expected Outcomes
153 |
154 | stdlib users will have a wide selection of PRNGs from which to choose from based on their individual needs and considerations. Having a large selection of PRNGs will useful when replicating the results of numerical simulations which may use a PRNG which is not one of the currently supported stdlib PRNGs. Additionally, a desired outcome would be if we could replace MT19937 with a new default PRNG.
155 |
156 | ### Involved Software
157 |
158 | No other software should be necessary. We may be a bit constrained based on 32-bit limitations in JS. This would not, however, stop us from implementing in C for use in generating arrays of random numbers.
159 |
160 | ### Prerequisite Knowledge
161 |
162 | JavaScript, Node.js. Familiarity with C/C++/Fortran would help.
163 |
164 | ### Difficulty
165 |
166 | Intermediate/Hard. Depends. Some PRNGs may be straightforward to implement. Others, not so much.
167 |
168 | ### Project Length
169 |
170 | 175/350 hours. This idea can be adjusted according to needs and availability.
171 |
172 | ### Potential Mentors
173 |
174 | @kgryte @Planeshifter @Pranavchiku
175 |
176 | * * *
177 |
178 | ## Add support for visualizing benchmark results
179 |
180 | Linked issue:
181 |
182 | ### Idea
183 |
184 | While we currently support running benchmarks, we have yet to provide a means for easily visualizing and comparing benchmark results. Previously, when wanting to visualize and compare benchmark results, one has needed to manually parse TAP results and then plug into some other software (e.g., vega or Plotly).
185 |
186 | The idea for this project would be to 1) implement a TAP parser with support for the latest TAP specification and 2) provide a plot frontend for consuming parsed TAP results. The plot frontend could be as simple as a Unicode bar chart plotter, which would be in line with our existing Unicode plotting facilities.
187 |
188 | ### Expected Outcomes
189 |
190 | Developers will be able to run benchmarks and visually compare benchmark results based on the namespace and parameterization. Ideally, the plot would include small multiple/facet visualizations.
191 |
192 | ### Involved Software
193 |
194 | No other software or dependencies should be necessary. Will need to consult a reference TAP parser implementation (e.g., `node-tap`).
195 |
196 | ### Prerequisite Knowledge
197 |
198 | JavaScript and Node.js.
199 |
200 | ### Difficulty
201 |
202 | Intermediate.
203 |
204 | ### Project Length
205 |
206 | 350 hours.
207 |
208 | ### Potential Mentors
209 |
210 | @kgryte @Planeshifter @steff456
211 |
212 | * * *
213 |
214 | ## Develop a project test runner
215 |
216 | Linked issue:
217 |
218 | ### Idea
219 |
220 | Currently, stdlib uses `tape`. The goal of this idea is to migrate away from `tape` and develop a test runner in-house, similar to `@stdlib/bench/harness`. This has long been on our TODO list and would allow us to have a simple test runner which is oriented toward stdlib conventions (e.g., we don't use most of the assertion methods in `tape`).
221 |
222 | Bonus points if we can migrate away from `istanbul` to `nyc` or `c8`; however, this may be tricky if we want to support older Node.js versions.
223 |
224 | ### Expected Outcomes
225 |
226 | All unit tests have migrated to the in-house runner.
227 |
228 | ### Involved Software
229 |
230 | No additional runtime deps. Will need to consult `tape` as a reference implementation, along with our existing `@stdlib/bench/harness` implementation.
231 |
232 | ### Prerequisite Knowledge
233 |
234 | JavaScript, Node.js.
235 |
236 | ### Difficulty
237 |
238 | Intermediate.
239 |
240 | ### Project Length
241 |
242 | 175/350 hours. The scope of this idea can be adjusted depending on availability.
243 |
244 | ### Potential Mentors
245 |
246 | @kgryte @Planeshifter @steff456
247 |
248 | * * *
249 |
250 | ## Reimagine the stdlib plot API and implementation
251 |
252 | Linked issue:
253 |
254 | ### Idea
255 |
256 | Currently, stdlib has a bespoke plot API which is useful for fast static rendering. However, our implementation is quite limited in the types of plots it can produce. The goal of this idea is to refactor our plot API to build atop of `vega` (or its specifications). For this, we'd need to migrate to an async plot generation API, which is probably necessary regardless if we want to support WebGL or some other async rendering engine.
257 |
258 | Ideally, we would retain the same plot API and internally generate a vega specification.
259 |
260 | ### Expected Outcomes
261 |
262 | We can generate simple plots using the new plot implementation.
263 |
264 | ### Involved Software
265 |
266 | This will involve using `vega` (or something similar depending on whether `vega` is sufficiently maintained). We will want to transpile to ES5 and vendor in order to ensure that we can support our supported Node.js versions.
267 |
268 | ### Prerequisite Knowledge
269 |
270 | JavaScript, Node.js.
271 |
272 | ### Difficulty
273 |
274 | Intermediate/Hard.
275 |
276 | ### Project Length
277 |
278 | 350 hours. This project has the potential to spiral out of control, as there are many unknowns we'd need to answer. Mentor would likely need to be actively involved in order to perform R&D and properly scope.
279 |
280 | ### Potential Mentors
281 |
282 | @kgryte @Planeshifter @rreusser
283 |
284 | * * *
285 |
286 | ## Achieve feature parity with async.js
287 |
288 | Linked issue:
289 |
290 | ### Idea
291 |
292 | Currently, stdlib has a limited set of dedicated "async" APIs for performing various utility operations. The goal of this idea is to achieve feature parity with [`async.js`](https://caolan.github.io/async/v3/), a popular library providing callback-based async APIs.
293 |
294 | Motivation for this idea stems from certain advantages afforded by callback-based asynchronous programming. Notable among them is superior performance and the ability to more readily return and inspect status objects.
295 |
296 | ### Expected Outcomes
297 |
298 | stdlib will have more or less 1:1 feature parity with `async.js` APIs.
299 |
300 | ### Involved Software
301 |
302 | `async.js` will serve as a reference implementation for API design. Will want to modify to match stdlib conventions.
303 |
304 | ### Prerequisite Knowledge
305 |
306 | JavaScript.
307 |
308 | ### Difficulty
309 |
310 | Beginner. Would benefit from someone with JavaScript experience.
311 |
312 | ### Project Length
313 |
314 | 175/350 hours. Can be scoped accordingly.
315 |
316 | ### Potential Mentors
317 |
318 | @kgryte @Planeshifter @steff456
319 |
320 | * * *
321 |
322 | ## Achieve feature parity with builtin Node.js `fs` module
323 |
324 | Linked issue:
325 |
326 | ### Idea
327 |
328 | Achieve feature parity with Node.js `fs` package. We currently only support a limited selection of `fs` methods. Would be useful to support more.
329 |
330 | Part of this work involves providing an abstraction layer of Node.js built-ins in order to support newer functionality (e.g., options and/or behavior) not present in older Node.js versions. This is similar in concept to the userland `readable-stream` package.
331 |
332 | ### Expected Outcomes
333 |
334 | stdlib will have complete feature parity with Node.js built-ins.
335 |
336 | ### Involved Software
337 |
338 | No other software is necessary.
339 |
340 | ### Prerequisite Knowledge
341 |
342 | JavaScript, Node.js.
343 |
344 | ### Difficulty
345 |
346 | Intermediate. Could require some creative solutions to ensure that abstractions work for older Node.js versions.
347 |
348 | ### Project Length
349 |
350 | 175/350 hours. Can be scoped accordingly.
351 |
352 | ### Potential Mentors
353 |
354 | @kgryte @Planeshifter @steff456
355 |
356 | * * *
357 |
358 | ## Add support for the multivariate normal distribution
359 |
360 | Linked issue:
361 |
362 | ### Idea
363 |
364 | The goal of this idea is to implement the multivariate normal distribution. This distribution is fundamental in a wide variety of statistical applications and will help unblock stdlib in offering additional statistics APIs.
365 |
366 | As a starting point, SciPy's multivariate normal distribution API and implementation could provide a suitable point of reference:
367 |
368 | - https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.multivariate_normal.html
369 |
370 | ### Expected Outcomes
371 |
372 | Users will be able to evaluate the PDF, CDF, logPDF, and logCDF and be able to draw random variates from a specified distribution.
373 |
374 | ### Involved Software
375 |
376 | No other software is necessary. Will require reading reference implementations written in Python, R, and Julia.
377 |
378 | ### Prerequisite Knowledge
379 |
380 | JavaScript, Node.js.
381 |
382 | ### Difficulty
383 |
384 | Intermediate.
385 |
386 | ### Project Length
387 |
388 | 175/350 hours. Can be scoped accordingly. A skilled contributor should be able to complete in 175 hours with the potential of using their implementation to implement higher order statistics APIs.
389 |
390 | ### Potential Mentors
391 |
392 | @kgryte @Planeshifter @Pranavchiku
393 |
394 | * * *
395 |
396 | ## Develop a Google Sheets extension which exposes stdlib functionality
397 |
398 | Linked issue:
399 |
400 | ### Idea
401 |
402 | The goal of this idea is to allow users to call stdlib APIs from within Google Sheets. This will allow users to perform linear algebra and various machine learning operations directly on spreadsheet data and all within the browser.
403 |
404 | In order to execute on this idea, we'll want to support
405 |
406 | - two-dimensional array broadcasting semantics
407 | - performant element-wise iteration APIs
408 | - input argument validation tailored to the Sheets context
409 | - Fused operations to avoid unnecessary network calls
410 | - documentation and tutorials demonstrating API usage
411 | - good generation and automation for creating extension builds
412 | - testing and performance measurement to guard against regressions
413 |
414 | ### Expected Outcomes
415 |
416 | Google Sheets users will be able to install an extension which exposes stdlib functionality, run statistical tests, evaluate mathematical functions, and perform linear algebra operations using stdlib.
417 |
418 | ### Involved Software
419 |
420 | No other software is necessary.
421 |
422 | ### Prerequisite Knowledge
423 |
424 | JavaScript, Node.js.
425 |
426 | ### Difficulty
427 |
428 | Beginner/Intermediate.
429 |
430 | ### Project Length
431 |
432 | 175/350 hours. Can be scoped accordingly. A skilled contributor can work on a strategy for performant fused operations.
433 |
434 | ### Potential Mentors
435 |
436 | @kgryte @Planeshifter @steff456
437 |
438 | * * *
439 |
440 | ## Stdlib API dependency explorer
441 |
442 | Linked issue:
443 |
444 | ### Idea
445 |
446 | stdlib is a large (and growing!) project, which can make project navigation challenging. The goal of this idea is to provide a visual representation of an API's dependency graph directly in the stdlib API documentation. Initial thinking is that would be an interactive network diagram in which nodes present package dependencies and allow for navigation; however, other visual representations may be possible.
447 |
448 | By providing such a means for navigating the project, users could more readily deepen their understanding of the `stdlib` code base, identify potential issues, and better understand how underlying APIs are used.
449 |
450 | ### Expected Outcomes
451 |
452 | A user will be able to navigate to a package's documentation page, click to display a network graph, and then click on nodes within that graph to explore the documentation of package dependencies.
453 |
454 | ### Involved Software
455 |
456 | No other software is necessary.
457 |
458 | ### Prerequisite Knowledge
459 |
460 | JavaScript, Node.js, HTML/CSS, JSX.
461 |
462 | ### Difficulty
463 |
464 | Beginner/Intermediate.
465 |
466 | ### Project Length
467 |
468 | 175 hours.
469 |
470 | ### Potential Mentors
471 |
472 | @kgryte @Planeshifter @steff456
473 |
474 | * * *
475 |
476 | ## Add support for bootstrap and jackknife resampling
477 |
478 | Linked issue:
479 |
480 | ### Idea
481 |
482 | Manually constructing confidence intervals and other statistical properties can be useful when no analytic solution exists. The goal of this idea to implement APIs for bootstrap and jackknife resampling.
483 |
484 | ### Expected Outcomes
485 |
486 | Users will be to resample provided datasets.
487 |
488 | ### Involved Software
489 |
490 | No other software is necessary.
491 |
492 | ### Prerequisite Knowledge
493 |
494 | JavaScript, Node.js.
495 |
496 | ### Difficulty
497 |
498 | Beginner/Intermediate.
499 |
500 | ### Project Length
501 |
502 | 175/350 hours. Can be scoped accordingly. Scope can be expanded to implement different bootstrap algorithms.
503 |
504 | * * *
505 |
506 | ## Develop a Jupyter backend for interfacing with the stdlib REPL
507 |
508 | Linked issue:
509 |
510 | ### Idea
511 |
512 | Jupyter is a dominate force in scientific computing. While some effort has been done to expose JavaScript kernels to Jupyter/JupyterLab, most of these kernels are under-developed or lack numerical functionality.
513 |
514 | The goal of this idea would be to develop a Jupyter backend based on stdlib.
515 |
516 | ### Expected Outcomes
517 |
518 | A JupyterLab user will be able to connect to a stdlib kernel and invoke stdlib operations.
519 |
520 | ### Involved Software
521 |
522 | This goal will require interfacing with the Jupyter technology stack, including ZeroMQ and implementing messaging protocols.
523 |
524 | ### Prerequisite Knowledge
525 |
526 | JavaScript, Node.js. Experience with Python would be very helpful.
527 |
528 | ### Difficulty
529 |
530 | Hard.
531 |
532 | ### Project Length
533 |
534 | 350 hours. This idea has many unknowns and will be hard to scope.
535 |
536 | ### Potential Mentors
537 |
538 | @kgryte @Planeshifter
539 |
540 | * * *
541 |
542 | ## Implement additional statistical tests
543 |
544 | Linked issue:
545 |
546 | ### Idea
547 |
548 | Implement various statistical tests which are not currently implemented in stdlib, but are implemented in other envs such as R, Python (SciPy, statsmodels), Julia, and MATLAB.
549 |
550 | ### Expected Outcomes
551 |
552 | stdlib will have a broader array of statistical tests which can operate on ndarrays.
553 |
554 | ### Involved Software
555 |
556 | No other software should be necessary. However, we will need to do a needs analysis to determine which prerequisite packages/functionality is necessary in order to allow these tests to be implemented (e.g., BLAS, ndarray slicing, etc).
557 |
558 | ### Prerequisite Knowledge
559 |
560 | JavaScript, Node.js. Familiarity with R, Python, C/C++ would be very useful, as will need to consult reference implementations.
561 |
562 | ### Difficulty
563 |
564 | Hard. Depends on the reference implementation requirements and algorithmic difficulty.
565 |
566 | ### Project Length
567 |
568 | 350 hours.
569 |
570 | ### Potential Mentors
571 |
572 | @kgryte @Planeshifter @Pranavchiku
573 |
574 | * * *
575 |
576 | ## Generate web documentation from JSDoc comments
577 |
578 | Linked issue:
579 |
580 | ### Idea
581 |
582 | stdlib relies heavily on JSDoc comments to document its source code. Currently, the project has only rudimentary support for generating HTML docs from those comments. The goal of this idea would be to
583 |
584 | 1. Write an in-house JSDoc parser.
585 | 2. Generate HTML documentation from the parsed comments which is capable of supporting project conventions and its embrace of radical modularity.
586 |
587 | JSDoc comments are oriented toward JavaScript source files; however, stdlib also uses similar documentation practices for documenting C source files and `make` files. A possible extension to the in-house JSDoc parser would be to support these other source file types. As those file types may require separate AST parsers, supporting other file types is likely to require writing separate comment parsers for each source type.
588 |
589 | ### Expected Outcomes
590 |
591 | In addition to the current API documentation, a user will be able to navigate to a package's JSDoc documentation to gain more insight into supported input and output dtypes and implemented algorithms. This would be especially useful for rendering the extended JSDoc comment of elementary mathematical functions.
592 |
593 | ### Involved Software
594 |
595 | No other software is necessary.
596 |
597 | ### Prerequisite Knowledge
598 |
599 | JavaScript, Node.js, HTML/CSS.
600 |
601 | ### Difficulty
602 |
603 | Intermediate.
604 |
605 | ### Project Length
606 |
607 | 350 hours. The length can likely be scaled down; however, there are several unknowns, and it may not be straightforward to develop an in-house parser which caters to the unique structure and setup of stdlib. For advanced contributors, possibility to explore support for source file types other than JavaScript (e.g., C and `make`).
608 |
609 | ### Potential Mentors
610 |
611 | @kgryte @Planeshifter @steff456
612 |
613 | * * *
614 |
615 | ## Refactor generated TypeScript interface documentation
616 |
617 | Linked issue:
618 |
619 | ### Idea
620 |
621 | Currently, stdlib publishes TypeScript interface documentation in its web-based API documentation. The generated documentation monkey-patches `tsdoc` to handle generating documentation across the entire mono-repo. The goal of this project is to refactor/rethink this approach and provide a solution capable of addressing the unique constraints of the stdlib project.
622 |
623 | ### Expected Outcomes
624 |
625 | At a base level, it would be great if we had a working documentation render which did not require monkey-patching. A more difficult, but potentially more desirable, outcome would be if TypeScript documentation was not rendered as a separate website, but rather was integrated within the docs as simply another page/fragment.
626 |
627 | ### Involved Software
628 |
629 | No other software is necessary.
630 |
631 | ### Prerequisite Knowledge
632 |
633 | JavaScript, Node.js, HTML/CSS, TypeScript, JSX/React.
634 |
635 | ### Difficulty
636 |
637 | Intermediate.
638 |
639 | ### Project Length
640 |
641 | 175/350 hours. Length will depend on the nature of the proposed solution (e.g., needing to write a custom TypeScript parser vs modifying the existing tsdoc library).
642 |
643 | ### Potential Mentors
644 |
645 | @kgryte @Planeshifter @steff456
646 |
647 | * * *
648 |
649 | ## Use ES6 modules for running unit tests and benchmarks in web browsers
650 |
651 | Linked issue:
652 |
653 | ### Idea
654 |
655 | Currently, when generating stdlib API documentation, we generate UMD bundles for unit tests and benchmarks. When a user navigates to our package documentation, they can load unit tests and benchmarks and have those run without needing to setup a local environment. The pain point here is that creating separate bundles for each package is time consuming and adds significant heft to the `www` repo.
656 |
657 | The goal of this idea is to refactor the way we support unit tests and benchmarks to use ES6 modules and potentially skip bundling altogether. This has the downside of not supporting older browsers which don't support the `` tag, but is probably fine considering that running package unit tests and benchmarks is likely a forward looking concern.
658 |
659 | ### Expected Outcomes
660 |
661 | Users will be able to run unit tests and benchmarks directly in their web browsers by navigating to project API documentation and what is loaded are ES6 modules, not UMD bundles.
662 |
663 | ### Involved Software
664 |
665 | No other software is necessary.
666 |
667 | ### Prerequisite Knowledge
668 |
669 | JavaScript, Node.js, HTML/CSS, JSX/React.
670 |
671 | ### Difficulty
672 |
673 | Intermediate.
674 |
675 | ### Project Length
676 |
677 | 350 hours.
678 |
679 | ### Potential Mentors
680 |
681 | @kgryte @Planeshifter @steff456
682 |
683 | * * *
684 |
685 | ## Migrate web API documentation to use matomo and instrument for better understanding user navigation behavior
686 |
687 | Linked issue:
688 |
689 | ### Idea
690 |
691 | Currently, the stdlib web-based API docs use GA for analytics and have only minimal integration. E.g., the API docs application is a SPA which uses React and the app does not record changes in page views; we only record first hits.
692 |
693 | The goal of this idea is to migrate to using matomo and take advantage of its privacy features. The work will involve instrumenting the API documentation application and integrating with matomo. A potential stretch goal would be to setup dashboards for reporting so that we can better understand user behavior and continue to improve project documentation.
694 |
695 | ### Expected Outcomes
696 |
697 | All user interaction data is logged to matomo and stored in a hosted database.
698 |
699 | ### Involved Software
700 |
701 | No other software is necessary.
702 |
703 | ### Prerequisite Knowledge
704 |
705 | JavaScript, Node.js, HTML/CSS, JSX/React.
706 |
707 | ### Difficulty
708 |
709 | Intermediate.
710 |
711 | ### Project Length
712 |
713 | 350 hours. Can be adjusted depending on skill and ability.
714 |
715 | ### Potential Mentors
716 |
717 | @kgryte @Planeshifter @steff456
718 |
719 | * * *
720 |
721 | ## Improve the REPL presentation framework
722 |
723 | Linked issue:
724 |
725 | ### Idea
726 |
727 | stdlib currently offers a REPL presentation framework for authoring presentations for use directly in the REPL. This is particularly useful for creating interactive tutorials illustrating how to use stdlib functionality for data analysis and visualization from the terminal. Some functionality is missing which would be quite useful. E.g.,
728 |
729 | - ASCII plotting
730 | - ASCII animations
731 | - syntax highlighting
732 | - pretty printing tables
733 | - speaker notes
734 | - multiplexing
735 | - theming
736 |
737 | ### Expected Outcomes
738 |
739 | The REPL presentation framework will have additional features similar to those in WYSIWYG presentation applications.
740 |
741 | ### Involved Software
742 |
743 | No other software is necessary.
744 |
745 | ### Prerequisite Knowledge
746 |
747 | JavaScript, Node.js.
748 |
749 | ### Difficulty
750 |
751 | Intermediate.
752 |
753 | ### Project Length
754 |
755 | 175/350 hours. Can be scoped according to project length.
756 |
757 | ### Potential Mentors
758 |
759 | @kgryte @Planeshifter @steff456
760 |
761 | * * *
762 |
763 | ## Functions for numerical integration and differentiation
764 |
765 | Linked issue:
766 |
767 | ### Idea
768 |
769 | The goal of this idea is to add functions for numerical integration or differentiation to stdlib as building blocks for downstream algorithms. The functions could be ported from permissively licensed open-source libraries in other languages such as C or Fortran or alternatively be implemented from scratch by consulting the literature and reference implementations from various languages.
770 |
771 | Some work along these lines has been started in the scijs ecosystem, which can be used for initial inspiration (e.g., https://github.com/scijs/ode45-cash-karp), and more generally in SciPy (e.g., https://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.ode.html).
772 |
773 | ### Expected Outcomes
774 |
775 | stdlib will have a range of robust functions for performing numerical integration or differentiation
776 |
777 | ### Involved Software
778 |
779 | No other software is necessary.
780 |
781 | ### Prerequisite Knowledge
782 |
783 | JavaScript, Node.js.
784 |
785 | ### Difficulty
786 |
787 | Intermediate.
788 |
789 | ### Project Length
790 |
791 | 350 hours.
792 |
793 | ### Potential Mentors
794 |
795 | @kgryte @Planeshifter @rreusser @Pranavchiku @czgdp1807
796 |
797 | * * *
798 |
799 | ## Symbolic Math
800 |
801 | Linked issue:
802 |
803 | ### Idea
804 |
805 | The goal of this idea is to add basic support for symbolic math operations in stdlib.
806 |
807 | ### Expected Outcome
808 |
809 | Users have the ability to perform basic symbolic math operations in JavaScript, such as solving equations, simplifying expressions, and using mathematical functions.
810 |
811 | ### Involved Software
812 |
813 | No other software should be necessary.
814 |
815 | ### Prerequisite Knowledge
816 |
817 | JavaScript, Node.js, and an understanding of mathematics and calculus.
818 |
819 | ### Difficulty
820 |
821 | Intermediate
822 |
823 | ### Project Length
824 |
825 | 350 hours.
826 |
827 | ### Potential Mentors
828 |
829 | @kgryte @Planeshifter @rreusser
830 |
831 | * * *
832 |
833 | ## Make code blocks on website documentation interactive
834 |
835 | Linked issue:
836 |
837 | ### Idea
838 |
839 | Currently, all code blocks in the documentation at https://stdlib.io/docs/api/latest are static. To make example code more useful and engaging, it would be nice to have interactive code shells on the website that could be edited and would provide real-time return annotations.
840 |
841 | Some initial brainstorming has been done to inform how this would work, but, at minimum, we'd need to
842 |
843 | - convert READMEs to structured data to allow for more straightforward transformation
844 | - support dynamic loading of relevant stdlib packages used in example code blocks
845 | - lazily integrate a code editor into documentation pages
846 | - implement security measures to prevent malicious usage
847 |
848 | ### Expected Outcomes
849 |
850 | Improved user experience on the website, as the code examples would become editable and interactive. Return annotations would have to update in real-time, and additional contextual help could be provided via overlays etc. Another outcome would be to make it easy to switch between ES5 and ES6 for code blocks.
851 |
852 | ### Involved Software
853 |
854 | No other software is necessary.
855 |
856 | ### Prerequisite Knowledge
857 |
858 | JavaScript, HTML/CSS, React + JSX
859 |
860 | ### Difficulty
861 |
862 | Hard.
863 |
864 | ### Project Length
865 |
866 | 350 hours.
867 |
868 | ### Potential Mentors
869 |
870 | @kgryte @Planeshifter @steff456
871 |
872 | * * *
873 |
874 | ## Optimization Algorithms
875 |
876 | Linked issue:
877 |
878 | ### Idea
879 |
880 | We currently do not have optimization algorithms in stdlib. Having support for Linear Programming, Convex Optimization, Quadratic Programming, and/or Non-Linear Optimization algorithms would be a great addition.
881 |
882 | ### Expected Outcomes
883 |
884 | stdlib will have a broad array of optimization algorithms for solving problems.
885 |
886 | ### Involved Software
887 |
888 | No other software should be necessary. However, we will need to do a needs analysis to determine which prerequisite packages/functionality is necessary in order to allow these algorithms to be implemented (e.g., BLAS).
889 |
890 | ### Prerequisite Knowledge
891 |
892 | JavaScript, Node.js. Familiarity with R, Python, C/C++ would be very useful, as will need to consult reference implementations.
893 |
894 | ### Difficulty
895 |
896 | Hard. Depends on the reference implementation requirements and algorithmic difficulty.
897 |
898 | ### Project Length
899 |
900 | 350 hours.
901 |
902 | ### Potential Mentors
903 |
904 | @kgryte @Planeshifter @rreusser @Pranavchiku @czgdp1807
905 |
906 | * * *
907 |
908 | ## Linear Algebra Functionality
909 |
910 | Linked issue:
911 |
912 | ### Idea
913 |
914 | Currently, support for linear algebra operations in stdlib is limited. The goal of this idea would be to implement algorithms for linear algebra operations such as matrix multiplication, calculating the matrix inverse, eigenvalue calculation, singular value decomposition, Cholesky & LU Decomposition, and the like. This overlaps with the goal of increasing the amount of BLAS and LAPACK that is available in stdlib.
915 |
916 | ### Expected Outcomes
917 |
918 | stdlib will have extended support for linear algebra operations which can be used to solve problems involving matrices and vectors.
919 |
920 | ### Involved Software
921 |
922 | No other software should be necessary. However, we will need to do a needs analysis to determine which prerequisite packages/functionality is necessary in order to allow these operations to be implemented (e.g., BLAS, ndarray slicing, etc).
923 |
924 | ### Prerequisite Knowledge
925 |
926 | JavaScript, Node.js. C, Fortran. Familiarity with linear algebra would be very useful, as will need to consult and understand reference implementations.
927 |
928 | ### Difficulty
929 |
930 | Hard. Depends on the reference implementation requirements and algorithmic difficulty.
931 |
932 | ### Project Length
933 |
934 | 350 hours.
935 |
936 | ### Potential Mentors
937 |
938 | @kgryte @Planeshifter @Pranavchiku @czgdp1807 @rreusser
939 |
940 | * * *
941 |
942 | ## Achieve ndarray API parity with built-in JavaScript arrays
943 |
944 | Linked issue:
945 |
946 | ### Idea
947 |
948 | Built-in JavaScript [arrays](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array) (and typed arrays) have a number of methods for creating, transforming, and manipulating array contents (e.g., `forEach`, `map`, `reverse`, `slice`, `filter`, etc). These APIs provide base level functionality forming a default vocabulary for working with array data.
949 |
950 | The goal of this idea is to create functional analogs of array methods for working with [ndarrays](https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/ndarray/ctor), which are efficient data structures for operating on multi-dimensional data. The main difficulty in implementing analogs is in ensuring efficient iteration of non-contiguous data. The main patterns for such iteration have been established in stdlib, but work remains to apply such patterns for top-level array-equivalent APIs.
951 |
952 | ### Expected Outcomes
953 |
954 | Users will be able to use functional APIs (exposed as part of individual packages) for operating on ndarrays in a manner similar to how users can use prototype methods available on built-in arrays and typed arrays.
955 |
956 | ### Involved Software
957 |
958 | No other software is necessary.
959 |
960 | ### Prerequisite Knowledge
961 |
962 | JavaScript, Node.js.
963 |
964 | For APIs not accepting callbacks, certain kernels can be implemented in C, as time and scope allow.
965 |
966 | ### Difficulty
967 |
968 | Intermediate. Writing the loop kernels can be involved, but, once understood, are straightforward to apply.
969 |
970 | ### Project Length
971 |
972 | 90/175/350 hours. Can be scoped accordingly. Scope can be expanded to implement additional ndarray kernels outside of Array method equivalents.
973 |
974 | ### Potential Mentors
975 |
976 | @kgryte @Planeshifter @steff456 @rreusser
977 |
978 | * * *
979 |
980 | ## Develop C implementations for base special mathematical functions
981 |
982 | Linked issue:
983 |
984 | ### Idea
985 |
986 | This idea builds on the work outlined in https://github.com/stdlib-js/stdlib/issues/649. Namely, implementing base special mathematical functions in C. Currently, all special mathematical functions have JavaScript implementations, which are often ports from other languages.
987 |
988 | The goal of this idea is to port all JavaScript implementations to C. Having such implementations will allow stdlib to provide Node.js native add-ons for higher performance ndarray computation and is more generally necessary for achieving NumPy/SciPy parity.
989 |
990 | ### Expected Outcomes
991 |
992 | Users will be able to leverage C implementations for use in Node.js native add-ons, and stdlib will be able to expose element-wise APIs for evaluating base special math functions over ndarrays.
993 |
994 | ### Involved Software
995 |
996 | No other software is necessary.
997 |
998 | ### Prerequisite Knowledge
999 |
1000 | C, JavaScript, Node.js.
1001 |
1002 | ### Difficulty
1003 |
1004 | Intermediate. Familiarity with C is beneficial. This idea mainly involves porting existing implementations (many of which are written in C/C++) and doing so in a manner which conforms with stdlib conventions.
1005 |
1006 | ### Project Length
1007 |
1008 | 90/175/350 hours. Can be scoped accordingly. Scope can be expanded to implement new special mathematical functions.
1009 |
1010 | ### Potential Mentors
1011 |
1012 | @kgryte @Planeshifter @steff456 @rreusser @Pranavchiku @czgdp1807
1013 |
1014 | * * *
1015 |
1016 | ## Develop an Excel add-on which exposes stdlib functionality
1017 |
1018 | Linked issue:
1019 |
1020 | ### Idea
1021 |
1022 | The goal of this idea is to allow users to call stdlib APIs from within Excel. This will allow users to perform linear algebra and various machine learning operations directly on spreadsheet data and all within the browser.
1023 |
1024 | In order to execute on this idea, we'll want to support
1025 |
1026 | - two-dimensional array broadcasting semantics
1027 | - performant element-wise iteration APIs
1028 | - input argument validation tailored to the Sheets context
1029 | - Fused operations to avoid unnecessary network calls
1030 | - documentation and tutorials demonstrating API usage
1031 | - good generation and automation for creating extension builds
1032 | - testing and performance measurement to guard against regressions
1033 |
1034 | This idea is the Excel version of https://github.com/stdlib-js/google-summer-of-code/issues/13.
1035 |
1036 | ### Expected Outcomes
1037 |
1038 | Excel users will be able to install an extension which exposes stdlib functionality, run statistical tests, evaluate mathematical functions, and perform linear algebra operations using stdlib.
1039 |
1040 | ### Involved Software
1041 |
1042 | No other software is necessary; however, access to a local copy of Excel will be beneficial. While Microsoft 360 can be used, debugging is more difficult and less stable.
1043 |
1044 | ### Prerequisite Knowledge
1045 |
1046 | JavaScript, Node.js.
1047 |
1048 | ### Difficulty
1049 |
1050 | Beginner/Intermediate.
1051 |
1052 | ### Project Length
1053 |
1054 | 175/350 hours. Can be scoped accordingly. A skilled contributor can work on a strategy for performant fused operations.
1055 |
1056 | ### Potential Mentors
1057 |
1058 | @kgryte @Planeshifter @steff456
1059 |
1060 | * * *
1061 |
1062 | ## Add BLAS bindings and implementations for linear algebra
1063 |
1064 | Linked issue:
1065 |
1066 | ### Idea
1067 |
1068 | [BLAS](https://netlib.org/blas/) routines are standard building blocks for performing basic vector and matrix operations. These building blocks are leveraged by most modern numerical programming languages and libraries, including NumPy, SciPy, Julia, MATLAB, R, and others.
1069 |
1070 | The goal of this idea is to
1071 |
1072 | - reimplement reference BLAS routines in free-form Fortran 95
1073 | - port reference BLAS routines to C
1074 | - port reference BLAS routines to JavaScript
1075 | - write Node.js bindings to allow calling BLAS routines in compiled C/ Fortran from JavaScript
1076 |
1077 | ### Expected Outcomes
1078 |
1079 | Users will be able to call BLAS routines from JavaScript. In web browsers, BLAS routines will be in JavaScript. In Node.js, provided native bindings have been compiled, BLAS routines will either be ported reference implementations or hardware optimized system libraries.
1080 |
1081 | ### Involved Software
1082 |
1083 | No other software is necessary apart from standard compilers (GCC, gfortran).
1084 |
1085 | ### Prerequisite Knowledge
1086 |
1087 | C, Fortran, JavaScript, Node.js.
1088 |
1089 | ### Difficulty
1090 |
1091 | Intermediate. Familiarity with C and Fortran will be beneficial. This idea mainly involves porting existing implementations and doing so in a manner which conforms with stdlib conventions.
1092 |
1093 | ### Project Length
1094 |
1095 | 90/175/350 hours. Can be scoped accordingly.
1096 |
1097 | ### Potential Mentors
1098 |
1099 | @kgryte @Planeshifter @steff456 @rreusser @Pranavchiku @czgdp1807
1100 |
1101 | * * *
1102 |
1103 | ## Implement incremental (online) machine learning algorithms
1104 |
1105 | Linked issue:
1106 |
1107 | ### Idea
1108 |
1109 | The goal of this idea is to implement incremental machine learning algorithms to allow for real-time regression and classification. Such online algorithms would allow for point-by-point data processing and avoid the sometimes costly overhead of batch processing. Online algorithms are particularly useful in data streaming contexts (e.g., user clicks, photon collection, etc).
1110 |
1111 | While stdlib includes some incremental algorithms ([binary classification](https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/ml/incr/binary-classification), [k-means](https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/ml/incr/kmeans), and [stochastic gradient descent regression](https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/ml/incr/sgd-regression)), the project would benefit from additional algorithms.
1112 |
1113 | Individuals interested in pursuing this idea should be prepared to research possible algorithms and propose specific APIs.
1114 |
1115 | ### Expected Outcomes
1116 |
1117 | stdlib will expose one or more additional APIs for incremental machine learning.
1118 |
1119 | ### Involved Software
1120 |
1121 | No other software is necessary.
1122 |
1123 | ### Prerequisite Knowledge
1124 |
1125 | JavaScript, Node.js.
1126 |
1127 | ### Difficulty
1128 |
1129 | Intermediate. In order to implement ML algorithms, individuals will likely need to consult reference implementations written in other languages. Porting from these implementations may not be straightforward depending on the features involved.
1130 |
1131 | ### Project Length
1132 |
1133 | 90/175/350 hours. Can be scoped accordingly.
1134 |
1135 | ### Potential Mentors
1136 |
1137 | @kgryte @Planeshifter
1138 |
1139 | * * *
1140 |
1141 | ## Add support for string arrays in stdlib
1142 |
1143 | Linked issue:
1144 |
1145 | ### Idea
1146 |
1147 | Similar to what's described in https://github.com/stdlib-js/google-summer-of-code/issues/43, a need exists to expand array data type support beyond numeric data types. One such data type is a `string` data type. The rationale for having a dedicated string data type is for better interoperation between JavaScript and C, and this is particularly paramount for supporting ndarrays having a string data type, as much of ndarray iteration machinery is written in C.
1148 |
1149 | Accordingly, the goal of this project is to add a dedicated string typed array called a `StringArray`, which will support variable-length strings. This new array type should follow a similar path to that of [@stdlib/array/complex64](https://github.com/stdlib-js/stdlib/tree/5dbb01dba2b1b305c6a11b66652ee2e4ccac15e2/lib/node_modules/%40stdlib/array/complex64), which provides a typed array dedicated to single-precision complex floating-point numbers; namely, `StringArray` should support standard typed array methods, as well as provide accessors for getting and setting array elements.
1150 |
1151 | Note, however, that a `StringArray` should be a typed array. A `StringArray` should not wrap a "generic" array. Instead, the array should be backed by fixed length memory, similar to how [@stdlib/array/complex64](https://github.com/stdlib-js/stdlib/tree/5dbb01dba2b1b305c6a11b66652ee2e4ccac15e2/lib/node_modules/%40stdlib/array/complex64) is backed by a `Float32Array`. One possibility is backing `StringArray` instances with Node.js `Buffer` objects, which are, in turn, `Uint8Array`s.
1152 |
1153 | There are, however, some design considerations; namely, how to handle setting of array elements. In particular, what happens when a user attempts to update a `StringArray` element with a larger string? Does that lead to a new memory allocation and data copy? Or should elements have a fixed allocation to allow for elements to grow until some maximum size?
1154 |
1155 | As part of this project, not only will a new `StringArray` be added to the project, but it will be integrated throughout stdlib. This will entail adding support for `StringArray`s wherever arrays are accepted/used, following the same precedent established by [@stdlib/array/complex64](https://github.com/stdlib-js/stdlib/tree/5dbb01dba2b1b305c6a11b66652ee2e4ccac15e2/lib/node_modules/%40stdlib/array/complex64) and other custom array types in stdlib. This includes adding support for string arrays in ndarray APIs.
1156 |
1157 | **Prior Art**
1158 |
1159 | - Recent work in NumPy adding UTF-8 variable length string support: https://numpy.org/neps/nep-0055-string_dtype.html
1160 |
1161 | ### Expected outcomes
1162 |
1163 | The expected outcomes of this idea should be (1) creation of a new `@stdlib/array/string` package exposing a new typed array constructor, (2) support for `StringArray` instances throughout `@stdlib/array/*`, (3) support for `StringArray` instances as backing arrays for ndarrays (which may involve working with various C APIs), and (4) any other integration opportunities.
1164 |
1165 | ### Status
1166 |
1167 | While no work has been done to create a new `@stdlib/array/string` package, there exists prior art for adding custom typed arrays to stdlib; namely, `Complex64Array` and `Complex128Array`.
1168 |
1169 | ### Involved software
1170 |
1171 | No special software for initial work. Once work has progressed to ndarray support, will need access to a C compiler, as documented in the project development guide.
1172 |
1173 | ### Technology
1174 |
1175 | JavaScript, C, nodejs, native addons
1176 |
1177 | ### Other technology
1178 |
1179 | n/a
1180 |
1181 | ### Difficulty
1182 |
1183 | Intermediate/Advanced
1184 |
1185 | ### Difficulty justification
1186 |
1187 | This project is ambitious, as there are many design considerations which need to be addressed in order to ensure performance and allow for efficient JS/C interoperation.
1188 |
1189 | Additionally, there will be difficulty beyond the creation of a new `StringArray` class in finding all the various bits of code throughout the project which need to be updated in order to more universally support `StringArray` instances throughout stdlib on equal footing with other array data types.
1190 |
1191 | ### Prerequisite knowledge
1192 |
1193 | Familiarity and comfort with JavaScript would be highly recommended, given that this project will require considerable programming in JavaScript. Some familiarity with C would also be good, especially for string array integration with ndarrays.
1194 |
1195 | ### Project length
1196 |
1197 | 350hrs, as will likely involve a decent amount of R&D.
1198 |
1199 | ### Potential mentors
1200 |
1201 | @kgryte @Planeshifter
1202 |
1203 | * * *
1204 |
1205 | ## ESLint 9 Migration for JSON and YAML Linting
1206 |
1207 | Linked issue:
1208 |
1209 | ### Idea
1210 |
1211 | We will migrate stdlib-js to ESLint 9 to take advantage of new features, performance improvements, and enhanced file type support (including JSON and YAML). Additionally, this idea posits that we will create new ESLint rules that enforce project-specific coding standards for stdlib. This dual approach ensures both modern linting capabilities and adherence to stdlib’s code expectations and style guidelines.
1212 |
1213 | ### Expected outcomes
1214 |
1215 | - ESLint 9 Integration: A full migration of the linting infrastructure to ESLint 9.
1216 | - Extended File Support: Ability to lint not just JavaScript but also JSON and YAML files with the help of ESLint.
1217 | - New Custom Rules: New rules to enforce more of stdlib’s conventions.
1218 | - Enhanced Code Quality: Improved consistency and code quality by enforcing additional project-specific standards across the codebase.
1219 | - Updated Configurations: Comprehensive configuration updates that incorporate both ESLint 9 changes and the new custom rules.
1220 |
1221 | ### Status
1222 |
1223 | stdlib currently uses ESLint 8. The stdlib project already has an [extensive collection of custom lint rules](https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/_tools/eslint/rules).
1224 |
1225 | ### Involved software
1226 |
1227 | No additional external dependencies aside from ESLint.
1228 |
1229 |
1230 |
1231 |
1232 | ### Technology
1233 |
1234 | nodejs, JavaScript
1235 |
1236 | ### Other technology
1237 |
1238 | n/a
1239 |
1240 |
1241 | ### Difficulty
1242 |
1243 | 3
1244 |
1245 | ### Difficulty justification
1246 |
1247 | Migrating to ESLint 9 requires a detailed review of current linting configurations and potential refactoring of custom rules. The project will involve understanding new semantics and breaking changes introduced in ESLint 9, addressing compatibility issues, and integrating support for additional file types such as JSON and YAML and bespoke rules for these new file types. Additionally, thorough testing across various scenarios is necessary to ensure stability, making this a task that is intermediate in complexity.
1248 |
1249 |
1250 |
1251 | ### Prerequisite knowledge
1252 |
1253 | A thorough understanding of ESLint, including its configuration system and plugin architecture, is essential. Familiarity with JavaScript and Node.js is required, along with experience in developing custom linting rules. Additionally, knowledge of continuous integration and automated testing practices is recommended to ensure that any new linting rules integrate smoothly into stdlib’s development workflow.
1254 |
1255 |
1256 |
1257 | ### Project length
1258 |
1259 | 175
1260 |
1261 | * * *
1262 |
1263 | ## Improve `stdlib` publishing pipeline
1264 |
1265 | Linked issue:
1266 |
1267 | ### Idea
1268 |
1269 | stdlib is composed of thousands of individual packages. Managing this complexity requires an intricate publishing pipeline that handles automatic updates to repositories, generation of various bundle types, publishing packages to the npm registry, changelog generation, and more.
1270 |
1271 | The project aims to refactor the current workflows by breaking down the monolithic, feature-rich scripts ([example](https://github.com/stdlib-js/stdlib/blob/develop/lib/node_modules/%40stdlib/_tools/scripts/publish_packages.js)) into discrete, standalone tooling packages in the [_tools](https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/_tools) namespace, which can be independently tested and maintained.
1272 |
1273 | In addition, while we still will lean on GitHub Actions for the publishing flow, this project will ensure that our publishing pipeline will not be tightly coupled with it anymore.
1274 |
1275 | Goals of the refactoring will also include to improve logging and observability, enable rigorous testing and checkpointing, and the ability to trigger all steps locally via a CLI tool.
1276 |
1277 |
1278 | ### Expected outcomes
1279 |
1280 | - Having the publishing pipeline fully composed into modular packages.
1281 | - Each module having its own suite of unit tests.
1282 | - Integration tests and end-to-end tests for the entire workflow.
1283 | - Enhanced observability and diagnostic tools integrated into the publishing process.
1284 | - A reduction in the complexity of the existing scripts by making GitHub Actions interactions explicit and manageable.
1285 | - Better error recovery, collection of statistics, and a more maintainable architecture.
1286 |
1287 | ### Status
1288 |
1289 | No effort has been undertaken to start modularizing the publishing pipeline architecture, but there is agreement among the TSC that this is a desirable goal.
1290 |
1291 | ### Involved software
1292 |
1293 | GitHub Actions, Bash.
1294 |
1295 | ### Technology
1296 |
1297 | JavaScript, nodejs
1298 |
1299 | ### Other technology
1300 |
1301 | None.
1302 |
1303 | ### Difficulty
1304 |
1305 | 3
1306 |
1307 | ### Difficulty justification
1308 |
1309 | The project involves a large refactor of an existing, complex system.
1310 |
1311 | - Decoupling the interwoven dependencies of the current monolithic script requires careful planning and modular design.
1312 | - Handling platform variability between local development and GitHub Actions orchestration, including differences between Linux and MacOS, adds complexity.
1313 | - Introducing enhanced testing and observability requires integrating new tools and extending the current functionality.
1314 |
1315 |
1316 | ### Prerequisite knowledge
1317 |
1318 | - Proficiency in JavaScript and Node.js development as well as Bash scripting.
1319 | - Familiarity with GitHub Actions and CI/CD pipeline design.
1320 | - Understanding of modular design principles and software refactoring techniques.
1321 |
1322 |
1323 | ### Project length
1324 |
1325 | 350
1326 |
1327 | * * *
1328 |
1329 | ## Add support for `Float16Array`
1330 |
1331 | Linked issue:
1332 |
1333 | ### Idea
1334 |
1335 | With `Float16Array` now on track for stage 4 approval in JavaScript (see https://github.com/tc39/proposal-float16array/issues/7), it is time we start thinking about adding support for `Float16Array` in stdlib. We have prior experience adding new array types, such as `array/bool`, `array/complex128`, and `array/complex64`, and this idea is a continuation of those efforts.
1336 |
1337 | The expected roadmap is as follows:
1338 |
1339 | - add a new `array/float16` package which includes a polyfill for backward compatibility support. The polyfill should expose all common methods and properties as found on other typed array constructors. This package should contain complete tests, documentation, and benchmarks, as found in other typed array packages (e.g., `array/bool`).
1340 | - add support for `float16` array dtypes throughout the `array/*` namespace.
1341 | - add support for `float16` array dtypes throughout the `strided/*` namespace.
1342 | - add support for `float16` array dtypes throughout the `ndarray/*` namespace.
1343 |
1344 | ### Expected outcomes
1345 |
1346 | stdlib users will be able to create and operate on `Float16Array` instances the same way they do throughout the project, with `Float16Array` on equal footing with all other typed array classes.
1347 |
1348 | ### Status
1349 |
1350 | No work has been done on this idea; however, we expect that this should follow as similar path to `array/bool` and its integration throughout the project.
1351 |
1352 | Related: https://github.com/stdlib-js/google-summer-of-code/issues/43
1353 |
1354 | ### Involved software
1355 |
1356 | No special software for initial work. Once work has progressed to ndarray support, will need access to a C compiler, as documented in the project development guide.
1357 |
1358 | ### Technology
1359 |
1360 | JavaScript, C, nodejs, native addons
1361 |
1362 | ### Other technology
1363 |
1364 | None.
1365 |
1366 | ### Difficulty
1367 |
1368 | 4
1369 |
1370 | ### Difficulty justification
1371 |
1372 | Implementing the polyfill will likely take some time, with the need for adding additional functionality to support the implementation (e.g., bit manipulation utilities, math utils, etc).
1373 |
1374 | This project is ambitious, as arrays are fundamental to a lot of stdlib functionality; however, many of the more difficult integration aspects have already addressed given the widespread support for other array types throughout the project. The main project difficulty beyond the creation of a new `Float16Array` class will be finding all the various bits of code throughout the project which need to be updated.
1375 |
1376 | ### Prerequisite knowledge
1377 |
1378 | Familiarity and comfort with JavaScript would be highly recommended, given that this project will require considerable programming in JavaScript. Some familiarity with C would also be good, especially for float16 array integration with ndarrays.
1379 |
1380 | ### Project length
1381 |
1382 | 350
1383 |
1384 | * * *
1385 |
1386 | ## Add LAPACK bindings and implementations for linear algebra
1387 |
1388 | Linked issue:
1389 |
1390 | ### Idea
1391 |
1392 | [LAPACK](https://netlib.org/lapack/) routines are standard building blocks for performing basic vector and matrix operations. These building blocks are leveraged by most modern numerical programming languages and libraries, including NumPy, SciPy, Julia, MATLAB, R, and others.
1393 |
1394 | The goal of this idea is to
1395 |
1396 | - reimplement reference LAPACK routines in free-form Fortran 95
1397 | - port reference LAPACK routines to pure C
1398 | - port reference LAPACK routines to pure JavaScript
1399 | - write Node.js bindings to allow calling LAPACK routines in compiled C/ Fortran from JavaScript
1400 |
1401 | ### Expected outcomes
1402 |
1403 | Users will be able to call LAPACK routines from JavaScript. In web browsers, LAPACK routines will be in JavaScript. In Node.js, provided native bindings have been compiled, LAPACK routines will either be ported reference implementations or hardware optimized system libraries.
1404 |
1405 | ### Status
1406 |
1407 | Some work has begun toward this effort. See https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/lapack/base.
1408 |
1409 | ### Involved software
1410 |
1411 | No other software is necessary apart from standard compilers (GCC, gfortran).
1412 |
1413 | ### Technology
1414 |
1415 | C, JavaScript, Fortran, nodejs, native addons
1416 |
1417 | ### Other technology
1418 |
1419 | None.
1420 |
1421 | ### Difficulty
1422 |
1423 | 4
1424 |
1425 | ### Difficulty justification
1426 |
1427 | Familiarity with C and Fortran will be beneficial. This idea mainly involves porting existing implementations and doing so in a manner which conforms with stdlib conventions. Some of the reference implementations are likely to be quite involved and testing the correct output can be tricky, especially for lower-level helper routines.
1428 |
1429 | ### Prerequisite knowledge
1430 |
1431 | C, Fortran, JavaScript, Node.js.
1432 |
1433 | ### Project length
1434 |
1435 | 350
1436 |
1437 | * * *
1438 |
1439 | ## Extend stdlib's doctesting approach to C examples
1440 |
1441 | Linked issue:
1442 |
1443 | ### Idea
1444 |
1445 | We heavily rely on doctesting (see https://github.com/stdlib-js/stdlib/blob/develop/docs/doctest.md) to ensure that our Markdown and JSDoc examples are correct and do not become out-of-date. However, we currently have no such framework for ensuring that our C source code and Markdown examples are correct.
1446 |
1447 | The goal of this project would be to implement doctesting for C source code and associated Markdown examples. While the approach is likely to be similar (e.g., parsing source code in scripts, Markdown code blocks, and in DOXYGEN examples), the technology stack is likely to be different and will require some R&D, especially as we won't be able to rely on things like ESLint. Instead, we'll need other tooling for identifying `// returns` annotations, instrumenting examples to collect return values, resolving source files to compile, compiling source files, executing scripts, and asserting that the output results match expectation.
1448 |
1449 | ### Expected outcomes
1450 |
1451 | As part of our CI workflows and in local development, developers will be able to test that their C examples are correct.
1452 |
1453 | ### Status
1454 |
1455 | stdlib has its own doctesting framework for checking JavaScript examples. This should serve as inspiration and provide an idea of what we are looking for.
1456 |
1457 | ### Involved software
1458 |
1459 | C compilers, AST generators, and stdlib tooling.
1460 |
1461 | ### Technology
1462 |
1463 | C
1464 |
1465 | ### Other technology
1466 |
1467 | None.
1468 |
1469 | ### Difficulty
1470 |
1471 | 5
1472 |
1473 | ### Difficulty justification
1474 |
1475 | There is likely a need for R&D to determine the best tools and approach. For JavaScript examples, we are able to rely on the fact that we can lint and execute within the same JavaScript runtime. In this case, there will be additional steps needed to separately instrument, create temporary files, compile, execute, and collect.
1476 |
1477 | ### Prerequisite knowledge
1478 |
1479 | Experience with C and creating tooling will be beneficial.
1480 |
1481 | ### Project length
1482 |
1483 | 350
1484 |
1485 | * * *
1486 |
1487 | ## Add WebAssembly implementations for extended BLAS routines
1488 |
1489 | Linked issue:
1490 |
1491 | ### Idea
1492 |
1493 | We've worked toward compiling BLAS routines to WebAssembly and offering ergonomic APIs for interfacing between JavaScript and WebAssembly binaries (see https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/blas/base/wasm). The goal of this project would be to extend these efforts to the `blas/ext/base` namespace, such that, for each typed interface in `blas/ext/base/(d|s|c|z|)*`, there would be a corresponding WebAssembly package in `blas/ext/base/wasm/*`.
1494 |
1495 | ### Expected outcomes
1496 |
1497 | Users wanting to potentially accelerate computation of extended BLAS routines will be able to consume a corresponding WebAssembly API.
1498 |
1499 | ### Status
1500 |
1501 | Work has primarily happened in https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/blas/base/wasm. The efforts there would need to be replicated for the `blas/ext/base/wasm/*` namespace.
1502 |
1503 | ### Involved software
1504 |
1505 | Emscripten, which is necessary for compiling C to WebAssembly. stdlib already offers tooling for automatically installing the emsdk and getting things up and running.
1506 |
1507 | ### Technology
1508 |
1509 | C, JavaScript
1510 |
1511 | ### Other technology
1512 |
1513 | None.
1514 |
1515 | ### Difficulty
1516 |
1517 | 3
1518 |
1519 | ### Difficulty justification
1520 |
1521 | Given that most `blas/ext/base/*` routines are straightforward one-dimensional strided array interfaces, developing the wasm packages should be similarly straightforward. The main time-consuming task will be writing tests and documentation.
1522 |
1523 | ### Prerequisite knowledge
1524 |
1525 | Some familiarity with WebAssembly will be helpful. Experience with JavaScript.
1526 |
1527 | ### Project length
1528 |
1529 | 90/175/350. Can be scoped accordingly.
1530 |
1531 | * * *
1532 |
1533 | ## Add WebAssembly implementations for `stats/strided` routines
1534 |
1535 | Linked issue:
1536 |
1537 | ### Idea
1538 |
1539 | We've worked toward compiling BLAS routines to WebAssembly and offering ergonomic APIs for interfacing between JavaScript and WebAssembly binaries (see https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/blas/base/wasm). The goal of this project would be to extend these efforts to the `stats/strided` namespace, such that, for each typed interface in `stats/strided/(d|s|c|z|)*`, there would be a corresponding WebAssembly package in `stats/strided/wasm/*`.
1540 |
1541 | ### Expected outcomes
1542 |
1543 | Users wanting to potentially accelerate computation of strided statistics routines will be able to consume a corresponding WebAssembly API.
1544 |
1545 | ### Status
1546 |
1547 | Work has primarily happened in https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/blas/base/wasm. The efforts there would need to be replicated for the `stats/strided/*` namespace.
1548 |
1549 | ### Involved software
1550 |
1551 | Emscripten, which is necessary for compiling C to WebAssembly. stdlib already offers tooling for automatically installing the emsdk and getting things up and running.
1552 |
1553 | ### Technology
1554 |
1555 | C, JavaScript
1556 |
1557 | ### Other technology
1558 |
1559 | None.
1560 |
1561 | ### Difficulty
1562 |
1563 | 3
1564 |
1565 | ### Difficulty justification
1566 |
1567 | Given that most `stats/strided/*` routines are straightforward one-dimensional strided array interfaces, developing the wasm packages should be similarly straightforward. The main time-consuming task will be writing tests and documentation.
1568 |
1569 | ### Prerequisite knowledge
1570 |
1571 | Some familiarity with WebAssembly will be helpful. Experience with JavaScript.
1572 |
1573 | ### Project length
1574 |
1575 | 90/175/350. Can be scoped accordingly.
1576 |
1577 | * * *
1578 |
1579 | ## Create a prototype for transpiling a subset of TypeScript to C with automatic add-on generation
1580 |
1581 | Linked issue:
1582 |
1583 | ### Idea
1584 |
1585 | Drawing on some of the recent innovations in the numerical Python ecosystem (e.g., see [`pyccel`](https://github.com/pyccel/pyccel/tree/devel)), the goal of this project would be to see if we can define a restricted subset of TypeScript which can be transpiled to C for faster execution in Node.js and other server runtimes.
1586 |
1587 | There is some prior art here; namely, [AssemblyScript](https://www.assemblyscript.org), which provides a TypeScript-like language which compiles to WebAssembly. However, we should be able to go farther here, especially in leveraging stdlib's richer collection of types (in particular, complex number dtypes). From this restricted subset, we can then automate transpilation of TypeScript to C, with the ability to automatically generate Node.js native add-ons bindings similar to what can be found in, e.g., https://github.com/stdlib-js/stdlib/blob/954e7c1e1716bfdd15903b4be7039741396927eb/lib/node_modules/%40stdlib/blas/base/dcopy/src/addon.c.
1588 |
1589 | There would be some puzzle pieces to put together here. Namely,
1590 |
1591 | - defining a richer set of numeric types. Currently, stdlib uses `number`, `boolean`, `Float64Array`, and other built-in types, along with a couple of custom types, such as `Complex128` and `Complex64`. We'd like want to create named aliases for specific numeric types, such as `int64`, `int32`, etc (similar to AssemblyScript). These would not impact consumption of project type declarations in TypeScript; although, they would have the benefit of signaling expected types.
1592 | - updating the TypeScript declarations for various packages (e.g., `blas/ext/base`) to use the newly defined types.
1593 | - creating tooling which can resolve and read a TypeScript declaration for an exported function and then automatically generate an `addon.c` file. If we can reproduce the [`addon.c`](https://github.com/stdlib-js/stdlib/blob/954e7c1e1716bfdd15903b4be7039741396927eb/lib/node_modules/%40stdlib/blas/base/dcopy/src/addon.c) file in `blas/base/dcopy`, that would be a win.
1594 | - potentially porting a subset of JavaScript implementations to TypeScript using the aliases defined above.
1595 | - from the ports, creating tooling which can, with high fidelity, generate one or more JavaScript implementations.
1596 | - from the ports, creating tooling which can, with high fidelity, generate one or more C implementations.
1597 |
1598 | Note that, when transpiling from TypeScript to C, we'd need to properly determine appropriate stdlib includes and dependencies. If we could auto-generate a basic `manifest.json` file, that could also be useful.
1599 |
1600 | We could also explore a TypeScript to Fortran transpiler.
1601 |
1602 | ### Expected outcomes
1603 |
1604 | A working end-to-end prototype which is capable of transpiling stdlib-flavored TypeScript to C and which can reproduce hand-authored C and JavaScript code.
1605 |
1606 | ### Status
1607 |
1608 | No work has begun on this.
1609 |
1610 | ### Involved software
1611 |
1612 | TypeScript and C/Fortran compilers.
1613 |
1614 | ### Technology
1615 |
1616 | C, JavaScript, native addons, Fortran
1617 |
1618 | ### Other technology
1619 |
1620 | None.
1621 |
1622 | ### Difficulty
1623 |
1624 | 4
1625 |
1626 | ### Difficulty justification
1627 |
1628 | This idea is exploratory, and, while conceptually straightforward, the project does involve a number of unknowns, particularly around how easy it will be to reproduce hand-optimized code. Given that the `blas/base/*`, `blas/ext/base/*`, and `stats/strided/*` namespaces provide a relatively contained environment for API design, it's possible that this will be achievable, but we won't know the best approach until after some R&D.
1629 |
1630 | ### Prerequisite knowledge
1631 |
1632 | TypeScript, C, and JavaScript experience would be beneficial.
1633 |
1634 | ### Project length
1635 |
1636 | 350
1637 |
1638 | * * *
1639 |
1640 | ## Add matrix format parsers and data loaders
1641 |
1642 | Linked issue:
1643 |
1644 | ### Idea
1645 |
1646 | The goal of this project would be to implement various matrix and multi-dimensional format parsers and data loaders. E.g.,
1647 |
1648 | - [Matrix Market](https://math.nist.gov/MatrixMarket/formats.html#MMformat)
1649 | - [NumPy `npy`](https://numpy.org/doc/stable/reference/generated/numpy.lib.format.html#module-numpy.lib.format)
1650 | - [DLPack](https://dmlc.github.io/dlpack/latest/)
1651 | - [MATLAB `mat`](https://www.mathworks.com/help/pdf_doc/matlab/matfile_format.pdf)
1652 | - others?
1653 |
1654 | Implementing these parsers and loaders would facilitate array data interchange with other numerical computing ecosystems.
1655 |
1656 | ### Expected outcomes
1657 |
1658 | Users will be able to load multi-dimensional array data saved in other numerical computing environments into stdlib's `ndarray` data structure.
1659 |
1660 | ### Status
1661 |
1662 | No work has begun on this.
1663 |
1664 | ### Involved software
1665 |
1666 | Access to MATLAB/Octave would be useful for implementing the MAT-file parser. One would likely need to use Python and NumPy in order to save and work with `npy` files.
1667 |
1668 | ### Technology
1669 |
1670 | JavaScript
1671 |
1672 | ### Other technology
1673 |
1674 | None.
1675 |
1676 | ### Difficulty
1677 |
1678 | 4
1679 |
1680 | ### Difficulty justification
1681 |
1682 | Some of the file format specifications can be quite involved. It is also likely that we may encounter situations in which we cannot support particular formats in full due to dtype incompatibility, etc.
1683 |
1684 | ### Prerequisite knowledge
1685 |
1686 | Familiarity with JavaScript, Python, and MATLAB would be useful. Experience writing parsers and performing IO will also be beneficial.
1687 |
1688 | ### Project length
1689 |
1690 | 90/175/350. Can be scoped accordingly.
1691 |
1692 | * * *
1693 |
1694 | ## Add support for working with arrays backed by memory-mapped files
1695 |
1696 | Linked issue:
1697 |
1698 | ### Idea
1699 |
1700 | Memory-mapped files allow accessing small segments of large disks stored on disk, without reading the entire file into memory. Not only can this be advantageous for memory performance, but it also facilitates shared memory between processes (e.g., operating on the same array in both Node.js and Python running in two separate processes).
1701 |
1702 | The goal of this project is to add support for working with typed arrays backed by memory-mapped files. Memory-mapped-backed typed arrays should support all the APIs of built-in typed arrays, with the exceptions that the constructors will need to support `mmap`-related arguments (e.g., filename, mode, offset) and indexing will require accessors, not square bracket syntax. The project is well-prepared to support accessors (see `array/bool`, `array/complex128`, etc), such that, provided a memory-mapped typed array supports the accessor protocol, passing to downstream utilities should just work.
1703 |
1704 | Similar to how we've approached fixed-endian typed arrays (see [`array/fixed-endian-factory`](https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/array/fixed-endian-factory)), we can likely create a package exposing a constructor factory and then create lightweight wrappers for type-specific constructors (e.g., [`array/little-endian-float64`](https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/array/little-endian-float64)).
1705 |
1706 | This project may require figuring out a strategy for C-JS iterop which can be used across constructors.
1707 |
1708 | ### Expected outcomes
1709 |
1710 | Ideally, we would have the following constructors:
1711 |
1712 | - `Float64ArrayMMap`
1713 | - `Float32ArrayMMap`
1714 | - `Int32ArrayMMap`
1715 | - `Int16ArrayMMap`
1716 | - `Int8ArrayMMap`
1717 | - `Uint32ArrayMMap`
1718 | - `Uint16ArrayMMap`
1719 | - `Uint8ArrayMMap`
1720 | - `Uint8ClampedArrayMMap`
1721 | - `BooleanArrayMMap`
1722 | - `Complex128ArrayMMap`
1723 | - `Complex64ArrayMMap`
1724 |
1725 | Additionally, the following constructors would also be useful:
1726 |
1727 | - `DataViewMMap`
1728 |
1729 | ### Status
1730 |
1731 | None.
1732 |
1733 | ### Involved software
1734 |
1735 | C compiler such as GCC or Clang.
1736 |
1737 | ### Technology
1738 |
1739 | C, JavaScript, nodejs, native addons
1740 |
1741 | ### Other technology
1742 |
1743 | None
1744 |
1745 | ### Difficulty
1746 |
1747 | 5
1748 |
1749 | ### Difficulty justification
1750 |
1751 | Figuring out an effective bridge between JavaScript and C for working with memory-mapped files will likely require some R&D. It is not clear whether we'd need to first develop separate dedicated `mmap(2)`-like functionality in JavaScript or whether we can directly interface into C. Once the lower-level details are determined, the next steps will be implementing all the user-facing APIs expected from typed arrays. This should be straightforward; however, there may be some unexpected challenges and constraints surrounding read-only access, etc.
1752 |
1753 | ### Prerequisite knowledge
1754 |
1755 | C, JavaScript, and Node.js experience will be useful.
1756 |
1757 | ### Project length
1758 |
1759 | 350
1760 |
1761 | * * *
1762 |
1763 | ## Improve project supply chain security by bringing production dependencies in-house
1764 |
1765 | Linked issue:
1766 |
1767 | ### Idea
1768 |
1769 | stdlib currently depends on [`14`](https://github.com/stdlib-js/stdlib/blob/develop/package.json#L55) external packages. Ideally, we'd reduce this number to `0` in order to (a) reduce the risk of supply-chain security vulnerabilities and (b) ensure that all production code used within stdlib follows the "stdlib way" (i.e., docs, tests, examples, benchmarks, backward-compatibility guarantees, etc).
1770 |
1771 | Accordingly, this project seeks to bring external packages "in-house" by implementing stdlib equivalents which can replace their usage within stdlib. Immediate targets are dependencies such as `debug`, `glob`, `resolve`, and `minimist` which we'd like to bring in-house for their own sake.
1772 |
1773 | Bringing `acorn` and friends in-house would likely require more work and impose an increased maintenance burden, so we'd want to be careful in determining whether we want to prioritize a stdlib implementation. That said, having a stdlib suite of JavaScript AST manipulators would be useful. The main concern is simply keeping up with yearly ECMAScript versions. If we stayed close enough to `acorn`, we could potentially just mirror changes into stdlib. Regardless, some thought would be required to determine whether we want to model any stdlib implementation after acorn or some other high-quality and performant AST parser third-party package.
1774 |
1775 | For `d3-*` and friends, these would likely go away once we migrated our plot functionality to use `vega`. So their priority is lower.
1776 |
1777 | For `vdom-to-html` and `virtual-dom`, these have been useful in the past; however, it is not clear whether these deserve inclusion in stdlib. They are currently used in the stdlib plot API. Similar to the `d3-*` packages, they might just naturally go away after migrating plot functionality to `vega`.
1778 |
1779 | `readable-stream` is a harder package to migrate. First and foremost, one should evaluate how much we actually need `readable-stream` and whether we can still retain desired backward compatible behavior with built-in Node.js streams. It is possible that the answer is yes; however, historically, using `readable-stream` has been critical in ensuring consistent behavior across Node.js versions.
1780 |
1781 | ### Expected outcomes
1782 |
1783 | Third-party party production dependencies would have equivalent stdlib implementations, and we can remove them as dependencies in the project `package.json`.
1784 |
1785 | ### Status
1786 |
1787 | No work has begun on this.
1788 |
1789 | ### Involved software
1790 |
1791 | None.
1792 |
1793 | ### Technology
1794 |
1795 | JavaScript, nodejs
1796 |
1797 | ### Other technology
1798 |
1799 | None.
1800 |
1801 | ### Difficulty
1802 |
1803 | 4
1804 |
1805 | ### Difficulty justification
1806 |
1807 | It depends on which dependencies are prioritized. Some, such as `acorn`, could be quite involved and require extensive testing. Others, such as `resolve` should be more straightforward. `glob` is likely to require significant R&D in order to understand and determine an ideal API.
1808 |
1809 | ### Prerequisite knowledge
1810 |
1811 | Experience and a high degree of comfort with JavaScript and Node.js.
1812 |
1813 | ### Project length
1814 |
1815 | 90/175/350. Scope can be tailored accordingly.
1816 |
1817 | * * *
1818 |
1819 | ## Automated Code Reviews and Fixes via LLM-powered stdlib-bot
1820 |
1821 | Linked issue:
1822 |
1823 | ### Idea
1824 |
1825 | Maintaining a large-scale open-source project like stdlib requires code review and automated tooling for linting, running tests, etc. Many small but important code fixes, such as formatting corrections, documentation improvements, and minor refactorings, are often flagged by maintainers but require manual intervention from contributors. This creates overhead and slows down the resolution of trivial issues.
1826 |
1827 | This project aims to leverage LLM-powered automation to streamline these processes. The core idea is to enhance `stdlib-bot` with the ability to not only surface review comments but also propose and submit fixes in the form of automated pull requests.
1828 |
1829 | In addition to automated code fixes, the project will explore fine-tuning an LLM on historical PR reviews and code comments to build an automated PR review assistant. This would allow` stdlib-bot` to provide real-time feedback on pull requests, flagging common mistakes based on past code review patterns and enforcing best practices in a scalable way.
1830 |
1831 | A broader goal of the project is to make stdlib more LLM-friendly. This may involve adding `llms.txt`, refining documentation formatting, and curating structured datasets (think of maintaining Cursor rules) to improve compatibility with AI-driven tooling.
1832 |
1833 | ### Expected outcomes
1834 |
1835 | - stdlib-bot automatically creates pull requests with suggested fixes based on commit comments; can be extended as an agent able to iteratively fix lint failures, formatting issues and test errors from CI workflow runs.
1836 | - Fine-tuning or retrieval-augmented generation (RAG) for automated PR review using past stdlib review comments (optional)
1837 | - Enhanced codebase compatibility with LLMs and AI code assistance (e.g., adding `llms.txt` or Cursor rules).
1838 | - Metrics to evaluate LLM-generated fixes and PR reviews.
1839 | - Integration with GitHub Actions for seamless automation.
1840 |
1841 | ### Status
1842 |
1843 | Currently, the stdlib-bot only reports necessary changes by creating issues, requiring human intervention. No automation of fixes or PR reviews exists yet.
1844 |
1845 | ### Involved software
1846 |
1847 | - GitHub Actions
1848 | - LLM APIs (e.g. OpenAI)
1849 | - GitHub REST or GraphQL API to collect data from past stdlib PR reviews
1850 |
1851 | ### Technology
1852 |
1853 | JavaScript, nodejs
1854 |
1855 | ### Other technology
1856 |
1857 | Depending on skill set and ambition of candidate, this can involve fine-tuning a model via the OpenAI Fine-Tuning APIs or from
1858 |
1859 | ### Difficulty
1860 |
1861 | 4
1862 |
1863 | ### Difficulty justification
1864 |
1865 | - Requires integrating LLMs with structured commit comments and generating meaningful PRs.
1866 | - Need to come up with robust validation strategy to ensure correctness of auto-generated fixes.
1867 | - Fine-tuning an LLM on past stdlib code review comments involves data collection, preprocessing, and iterative testing.
1868 |
1869 | ### Prerequisite knowledge
1870 |
1871 | Knowledge of Node.js / JavaScript, experience with GitHub Actions and CI/CD, understanding of LLM APIs and optionally fine-tuning methodologies. Familiarity with automated code refactoring tools is a plus.
1872 |
1873 | ### Project length
1874 |
1875 | 350
--------------------------------------------------------------------------------
/mentors.md:
--------------------------------------------------------------------------------
1 |
6 |
7 | # Mentors
8 |
9 | > Potential mentors.
10 |
11 | If you are willing to mentor,
12 |
13 | 1. read the [GSoC mentor guide](https://google.github.io/gsocguides/mentor/).
14 | 1. register at .
15 | 1. submit a pull request adding yourself to the list below, making sure (1) to include any project ideas that you'd be willing to mentor by linking to the relevant issue(s), (2) to provide your GitHub handle, and (3) to include the e-mail that you used to register at .
16 |
17 | ## Mentor List
18 |
19 | - Athan Reines
20 |
21 | - e-mail: [kgryte@gmail.com](mailto:kgryte@gmail.com)
22 | - GitHub: [kgryte](https://github.com/kgryte)
23 | - projects: all
24 |
25 | - Philipp Burckhardt
26 |
27 | - e-mail: [philipp.burckhardttc@gmail.com](mailto:philipp.burckhardttc@gmail.com)
28 | - GitHub: [planeshifter](https://github.com/planeshifter)
29 | - projects: all
30 |
31 | - Gagandeep Singh
32 |
33 | - e-mail: [gdp.1807@gmail.com](mailto:gdp.1807@gmail.com)
34 | - GitHub: [czgdp1807](https://github.com/czgdp1807)
35 | - projects: anything involving implementation of mathematical functions or array programming
36 |
37 | - Ricky Reusser
38 |
39 | - e-mail: [rsreusser@gmail.com](mailto:rsreusser@gmail.com)
40 | - GitHub: [rreusser](https://github.com/rreusser)
41 | - projects: most, with particular interest in those involving numerics
42 |
43 | - Pranav Goswami
44 |
45 | - e-mail: [pranavchiku11@gmail.com](mailto:pranavchiku11@gmail.com)
46 | - GitHub: [pranavchiku](https://github.com/pranavchiku)
47 | - projects: most, particularly implementation of BLAS and mathematical functions
48 |
49 | - Stephannie Jimenez Gacha
50 |
51 | - e-mail: [steff456@hotmail.com](steff456@hotmail.com)
52 | - GitHub: [steff456](https://github.com/steff456)
53 | - projects: implementation of mathematical functions and Google Sheets APIs
54 |
55 | - Robert Gislason
56 |
57 | - e-mail: [gztown2216@yahoo.com](mailto:gztown2216@yahoo.com)
58 | - GitHub: [rgizz](https://github.com/rgizz)
59 | - projects: all
60 |
61 | - Gunj Joshi
62 |
63 | - e-mail: [gunjjoshi8372@gmail.com](mailto:gunjjoshi8372@gmail.com)
64 | - GitHub: [gunjjoshi](https://github.com/gunjjoshi)
65 | - projects: all
66 |
67 | - Snehil Shah
68 |
69 | - e-mail: [snehilshah.989@gmail.com](mailto:snehilshah.989@gmail.com)
70 | - GitHub: [Snehil-Shah](https://github.com/Snehil-Shah)
71 | - projects: most. Particularly around interactive computing, data visualization, project tooling, and developer tools/integrations.
72 |
73 | - Jaysukh Makvana
74 |
75 | - e-mail: [jaysukhmakvana2004@gmail.com](mailto:jaysukhmakvana2004@gmail.com)
76 | - GitHub: [Jaysukh-409](https://github.com/Jaysukh-409)
77 | - projects: most, particularly implementations of mathematical functions and array related tasks
78 |
79 | - Aman Bhansali
80 |
81 | - e-mail: [amanbhansali65@gmail.com](mailto:amanbhansali65@gmail.com)
82 | - GitHub: [aman-095](https://github.com/aman-095)
83 | - projects: most, particularly implementation of BLAS, LAPACK and related mathematical functions
84 |
85 | ## Time Commitment
86 |
87 | For primary mentors, we expect between a 3-10 hour a week commitment, where the requisite time decreases over the course of the program. Mentors can expect to spend more time the first few weeks prior to the contributor start date, where you'll be helping flesh out the project ideas, discussing projects with potential contributors, and selecting contributors based on their submitted proposals. Once contributors are selected and the program kicks off, your commitment should decrease to 2-4 hours a week and be comprised of a weekly 1 hour 1-on-1 where you'll establish rapport and discuss project progress and of some additional time to perform code review and answer questions as they arise. Ideally, a mentor will pair program with a contributor for 1 hour every two weeks throughout the duration of the program.
88 |
89 | ## Required Knowledge
90 |
91 | In general, **successful mentors are those who are already developers and community members of stdlib**. If you're new to stdlib, expect to take time to learn the ropes yourself so that you are in a position to help GSoC contributors.
92 |
93 | Mentors do not have to be be experts in all things stdlib. Much of what mentors do is keeping contributors on track and helping them get unstuck when they encounter unexpected obstacles. Sometimes that means just knowing who and what to ask and where to look rather than knowing the answer yourself. In an ideal world, a mentor can answer basic architectural questions and knows how to get code accepted upstream (e.g., is deeply familiar with project conventions, practices, and development workflows).
94 |
95 | ## Contributor Evaluations
96 |
97 | Mentors must perform multiple evaluations on each GSoC contributor, two mid-terms and one at the end. Evaluations typically consist of a few questions about how the GSoC contributor is doing and then a pass/fail that determines if the GSoC contributor is paid and continues in the program.
98 |
--------------------------------------------------------------------------------
/organization/README.md:
--------------------------------------------------------------------------------
1 |
6 |
7 | # Organization
8 |
9 | > Organization materials and resources for Google Summer of Code.
10 |
11 | * * *
12 |
13 | ## License
14 |
15 | Reuse and redistribution of the materials in this directory (and its descendant directories) is **not** permitted without the express written consent of The Stdlib Authors.
16 |
--------------------------------------------------------------------------------
/organization/applications/2023.md:
--------------------------------------------------------------------------------
1 |
6 |
7 | # Application
8 |
9 | > Google Summer of Code organization application for 2023.
10 |
11 | **Note**: do not use any markup in this document in order to make it easier to copy and paste answers into the official application document.
12 |
13 | Each answer must **not** exceed 1000 characters.
14 |
15 | ## Questionnaire
16 |
17 | ### Why does your organization want to participate in Google Summer of Code (GSoC)?
18 |
19 | First and foremost, we want to leverage GSoC as an opportunity to grow our community and introduce new contributors to open source. While we realize that many contributors will move on to other endeavors after GSoC is over, our hope is that some GSoC contributors will find a home in the stdlib community, continue contributing to the project, and eventually join the stdlib core development team where they'll have a direct hand in shaping the future of open source.
20 |
21 | Second, GSoC gives new contributors an opportunity to be paid to work on stdlib--an opportunity that most core stdlib developers do not have--and gives stdlib the opportunity to pursue projects which are of fundamental importance but lack sufficient people power to bring to completion.
22 |
23 | ### What would your organization consider to be a successful GSoC program?
24 |
25 | We want contributors to take on projects which are important to stdlib and to implement them successfully, thus improving stdlib. A successful program is thus one in which (a) GSoC contributors are having fun, learning, and feeling excited about their work, (b) GSoC contributors have, on average, at least one merged pull request every two weeks, (c) GSoC contributors continue interacting with our community outside of their project and continue contributing after the program is over, and (d) the stdlib community benefits from the conversations, new perspectives, and unique talents that each GSoC contributor will bring while working on projects of fundamental importance.
26 |
27 | ### How will you keep mentors engaged with their GSoC contributors?
28 |
29 | Most stdlib mentors have either mentored as part of GSoC or elsewhere or were GSoC contributors in the past. We require that mentors be existing contributors to stdlib and be familiar with both the code and the project area. We further require that mentors and contributors interact and communicate publicly in order to encourage participation from the greater stdlib community. And lastly, we require that mentors and contributors meet at least once a week to discuss their project, preferably via video conferencing, and we strongly encourage that mentors pair program with contributors at least once every two weeks.
30 |
31 | Each project will have one or more backup or co-mentors, and no mentor is allowed to be a primary mentor for more than one project, or a backup or co-mentor for more than two projects. This may require taking fewer slots than we would like, but we believe this is better than stretching our mentoring capacity too thin and risking mentor burn out.
32 |
33 | ### How will you help your GSoC contributors stay on schedule to complete their projects?
34 |
35 | By holding weekly 1-on-1s and bi-weekly pair programming sessions, one of our primary goals will be to notice, as early as possible, when a contributor is struggling. Early identification of problems or potential slippages will allow us to quickly provide the support and resources a contributor needs to succeed and overcome encountered problems. We anticipate that, in most cases, if a contributor is struggling, a project's timeline will be found to be unrealistic or require modification due to, e.g., unforeseen technical challenges.
36 |
37 | If a contributor continues to struggle despite increased mentor support, we'll give a contributor a reasonable, mutually agreed upon set of goals to achieve in 1-2 weeks. If the contributor begins making sufficient progress (with our help), we will pass the contributor. Otherwise, we will fail the contributor.
38 |
39 | ### How will you get your GSoC contributors involved in your community during GSoC?
40 |
41 | Establishing a habit of open communication is vital for open source participation. We strongly encourage that all mentor-contributor interactions happen on a public channel, such as our public Gitter channel or on GitHub. For all weekly mentor-contributor meetings, we require that meeting minutes be posted to a public wiki. By encouraging public participation and communication, members of the greater stdlib community have opportunities to take part in project discussions, engage in community review, and provide feedback.
42 |
43 | GSoC contributors will be required to blog about their progress at least once each week. These blogs will be aggregated on a public wiki. We will further encourage GSoC contributors to help triage issues and review other pull requests, which is an excellent way to get involved in the stdlib community.
44 |
45 | ### Anything else we should know? (optional)
46 |
47 | N/A
48 |
49 | ### Is your organization part of any government? (yes or no)
50 |
51 | No.
52 |
53 | ### GSoC Reference Contact? (optional)
54 |
55 | > If you are an organization that has not been accepted into GSoC before, is there a Google employee or a veteran GSoC organization who will vouch for you? If so, please enter their name, contact email, relationship to your organization, and their role (Google employee, org admin of XX org, etc.)
56 |
57 | SymPy (veteran organization); Aaron Meurer: asmeurer@gmail.com; Aaron is a colleague and collaborator of Athan Reines at Quansight and a long time GSoC participant and mentor; org admin of SymPy org.
58 |
59 | Lee Richardson: leerich@google.com; Lee is a Senior Data Scientist and Tech Lead at Google and former colleague of Philipp Burckhardt during their PhD studies at Carnegie Mellon University, where they collaborated on converting a Shiny R tool to a Next.js web app; Google employee.
60 |
61 | * * *
62 |
63 | ## Organization Application
64 |
65 | ### Ideas List
66 |
67 | > Provide the URL for your organization's curated Ideas List for 2023. This is very important: Prospective GSoC Contributors will view this link to understand the kinds of projects available in your organization. A clean and simple presentation is best. Avoid links to unfiltered bug trackers or other specialized tools.
68 |
69 | https://github.com/stdlib-js/google-summer-of-code/blob/main/ideas.md
70 |
71 | ### Mentors (number)
72 |
73 | > How many Mentors does your Organization have available to participate in this program? (This is the number of people listed in our mentor document: .)
74 |
75 | 4
76 |
77 | ### Program Retention Survey
78 |
79 | > The last program your organization participated in was:
80 |
81 | N/A
82 |
83 | #### Number of accepted students/GSoC contributors? (number)
84 |
85 | N/A
86 |
87 | #### Number of participants who are still active today? (number)
88 |
89 | N/A
90 |
91 | ### Is your organization part of any government? (yes or no)
92 |
93 | > This will not affect your selection into the program. However, as stated in the Program Rules, we can not issue org stipends to orgs that are part of any government. This includes public universities, government research institutions, etc.
94 |
95 | No.
96 |
97 | ### Anything else we should know? (optional)
98 |
99 | > Must be less than or equal to 500 characters.
100 |
101 | N/A
102 |
103 | * * *
104 |
105 | ## Profile Information
106 |
107 | > Information for the GSoC profile.
108 |
109 | ### Name
110 |
111 | stdlib
112 |
113 | ### Website URL
114 |
115 | https://stdlib.io
116 |
117 | ### Upload logo
118 |
119 | > 24-bit PNG, minimum height of 256 pixels.
120 |
121 | https://github.com/stdlib-js/google-summer-of-code/blob/main/organization/applications/logo.png
122 |
123 | ### Tagline
124 |
125 | > A very short description of your organization. Must be less than or equal to 50 characters.
126 |
127 | The fundamental numerical library for JavaScript
128 |
129 | ### Primary open source license
130 |
131 | > The open source license that your organization uses.
132 |
133 | Apache-2.0
134 |
135 | ### What year was your project started?
136 |
137 | 2017
138 |
139 | ### Link to your source code location
140 |
141 | https://github.com/stdlib-js/stdlib
142 |
143 | ### Organization categories
144 |
145 | > Select which categories fit your organization best. You may select up to 2 categories. This helps GSoC contributors filter the large list of organizations by their interests.
146 |
147 | - [ ] Data (databases, analytics, visualization, AI/ML, etc)
148 | - [ ] Development tools (version control systems, CICD tools, text editors, issue managers, q/a tools, etc)
149 | - [ ] End user applications
150 | - [ ] Infrastructure and cloud (hardware, software defined infrastructure, cloud native tooling, orchestration and automation, etc)
151 | - [ ] Media (graphics, video, audio, VR, streaming, gaming, content management, etc)
152 | - [ ] Operating systems
153 | - [x] Programming languages (libraries, package managers, testing tools, etc)
154 | - [ ] Science and medicine (healthcare, biotech, life sciences, academic research, etc)
155 | - [ ] Security (tools and frameworks)
156 | - [ ] Social and communications (Blog, chat, forums, wikis, etc)
157 | - [x] Web (tools and frameworks)
158 | - [ ] Other
159 |
160 | ### Organization technologies
161 |
162 | > Enter up to 5 keywords for the primary specific technologies your organization uses. Examples: Python, Javascript, MySQL, Hadoop, OpenGL, Arduino.
163 |
164 | JavaScript, Node.js, C
165 |
166 | ### Organization topics
167 |
168 | > Enter keywords for general topics that describe your organization. Examples: Robotics, Cloud, Graphics, Web, etc. Select up to 5.
169 |
170 | Scientific Computing, Mathematics, Statistics, Numerical Computing, Web
171 |
172 | ### Organization description
173 |
174 | > Describe what it is your organization does. This information will also be included in the archive once the program has ended.
175 |
176 | stdlib is a standard library for JavaScript and Node.js with an emphasis on numerical and scientific computing applications. The project aims to provide functionality similar to NumPy and SciPy for use in JavaScript environments with special consideration for the unique constraints and opportunities afforded by the Web. stdlib is primarily written in JavaScript, C, and Fortran.
177 |
178 | ### Contributor guidance
179 |
180 | > Provide your potential contributors with a page containing tips on how to write a successful proposal for your organization. Let them know what you want included, how you want it structured, and how to best get in touch.
181 |
182 | https://github.com/stdlib-js/google-summer-of-code
183 |
184 | ### Direct Communication methods
185 |
186 | > How do you want potential contributors to interact with your organization and mentors? Chat clients such as IRC, Zulip or Rocket Chat are very well suited to Google Summer of Code collaboration and are recommended. But email or other methods are also acceptable. Choose communications options from the dropdown below. One email or chat method required.
187 |
188 | chat; https://gitter.im/stdlib-js/stdlib
189 |
190 | ### Social Communication Methods
191 |
192 | > Social platforms for bi-directional communications can be useful in getting input from potential contributors. Choose social channel options from the dropdown below.
193 |
194 | Twitter; https://twitter.com/stdlibjs
195 |
--------------------------------------------------------------------------------
/organization/applications/2024.md:
--------------------------------------------------------------------------------
1 |
6 |
7 | # Application
8 |
9 | > Google Summer of Code organization application for 2024.
10 |
11 | **Note**: do not use any markup in this document in order to make it easier to copy and paste answers into the official application document.
12 |
13 | Each answer must **not** exceed 1000 characters.
14 |
15 | ## Questionnaire
16 |
17 | ### Why does your organization want to participate in Google Summer of Code (GSoC)?
18 |
19 | First and foremost, we want to leverage GSoC as an opportunity to grow our community and introduce new contributors to open source. While we realize that many contributors will move on to other endeavors after GSoC is over, our hope is that some GSoC contributors will find a home in the stdlib community, continue contributing to the project, and eventually join the stdlib core development team where they'll have a direct hand in shaping the future of open source.
20 |
21 | Second, GSoC gives new contributors an opportunity to be paid to work on stdlib--an opportunity that most core stdlib developers do not have--and gives stdlib the opportunity to pursue projects which are of fundamental importance but lack sufficient people power to bring to completion.
22 |
23 | ### What would your organization consider to be a successful GSoC program?
24 |
25 | We want contributors to take on projects which are important to stdlib and to implement them successfully, thus improving stdlib. A successful program is thus one in which (a) GSoC contributors are having fun, learning, and feeling excited about their work, (b) GSoC contributors have, on average, at least one merged pull request every week, (c) GSoC contributors continue interacting with our community outside of their project and continue contributing after the program is over, and (d) the stdlib community benefits from the conversations, new perspectives, and unique talents that each GSoC contributor will bring while working on projects of fundamental importance.
26 |
27 | ### How will you keep mentors engaged with their GSoC contributors?
28 |
29 | Most stdlib mentors have either mentored as part of GSoC or elsewhere or were GSoC contributors in the past. We require that mentors be existing contributors to stdlib and be familiar with both the code and the project area. We further require that mentors and contributors interact and communicate publicly in order to encourage participation from the greater stdlib community. And lastly, we require that mentors and contributors meet at least once a week to discuss their project, preferably via video conferencing, and we strongly encourage that mentors pair program with contributors at least once every two weeks.
30 |
31 | Each project will have one or more backup or co-mentors, and no mentor is allowed to be a primary mentor for more than one project, or a backup or co-mentor for more than two projects. This may require taking fewer slots than we would like, but we believe this is better than stretching our mentoring capacity too thin and risking mentor burn out.
32 |
33 | ### How will you help your GSoC contributors stay on schedule to complete their projects?
34 |
35 | By holding weekly 1-on-1s and bi-weekly pair programming sessions, one of our primary goals will be to notice, as early as possible, when a contributor is struggling. Early identification of problems or potential slippages will allow us to quickly provide the support and resources a contributor needs to succeed and overcome encountered problems. We anticipate that, in most cases, if a contributor is struggling, a project's timeline will be found to be unrealistic or require modification due to, e.g., unforeseen technical challenges.
36 |
37 | If a contributor continues to struggle despite increased mentor support, we'll give a contributor a reasonable, mutually agreed upon set of goals to achieve in 1-2 weeks. If the contributor begins making sufficient progress (with our help), we will pass the contributor. Otherwise, we will fail the contributor.
38 |
39 | ### How will you get your GSoC contributors involved in your community during GSoC?
40 |
41 | Establishing a habit of open communication is vital for open source participation. We strongly encourage that all mentor-contributor interactions happen on a public channel, such as our public Element channel or on GitHub. For all weekly mentor-contributor meetings, we require that meeting minutes be posted to a public wiki. By encouraging public participation and communication, members of the greater stdlib community have opportunities to take part in project discussions, engage in community review, and provide feedback.
42 |
43 | GSoC contributors will be required to blog about their progress at least once every two weeks. These blogs will be aggregated on a public wiki. We will further encourage GSoC contributors to help triage issues and review other pull requests, which is an excellent way to get involved in the stdlib community.
44 |
45 | ### Anything else we should know? (optional)
46 |
47 | N/A
48 |
49 | ### Is your organization part of any government? (yes or no)
50 |
51 | No.
52 |
53 | ### GSoC Reference Contact? (optional)
54 |
55 | > If you are an organization that has not been accepted into GSoC before, is there a Google employee or a veteran GSoC organization who will vouch for you? If so, please enter their name, contact email, relationship to your organization, and their role (Google employee, org admin of XX org, etc.)
56 |
57 | SymPy (veteran organization); Aaron Meurer: asmeurer@gmail.com; Aaron is a colleague and collaborator of Athan Reines at Quansight and a long time GSoC participant and mentor; org admin of SymPy org.
58 |
59 | Lee Richardson: leerich@google.com; Lee is a Senior Data Scientist and Tech Lead at Google and former colleague of Philipp Burckhardt during their PhD studies at Carnegie Mellon University, where they collaborated on converting a Shiny R tool to a Next.js web app; Google employee.
60 |
61 | * * *
62 |
63 | ## Organization Application
64 |
65 | ### Ideas List
66 |
67 | > Provide the URL for your organization's curated Ideas List for 2024. This is very important: Prospective GSoC Contributors will view this link to understand the kinds of projects available in your organization. A clean and simple presentation is best. Avoid links to unfiltered bug trackers or other specialized tools.
68 |
69 | https://github.com/stdlib-js/google-summer-of-code/blob/main/ideas.md
70 |
71 | ### Mentors (number)
72 |
73 | > How many Mentors does your Organization have available to participate in this program? (This is the number of people listed in our mentor document: .)
74 |
75 | 7
76 |
77 | ### Program Retention Survey
78 |
79 | > The last program your organization participated in was:
80 |
81 | N/A
82 |
83 | #### Number of accepted students/GSoC contributors? (number)
84 |
85 | N/A
86 |
87 | #### Number of participants who are still active today? (number)
88 |
89 | N/A
90 |
91 | ### Is your organization part of any government? (yes or no)
92 |
93 | > This will not affect your selection into the program. However, as stated in the Program Rules, we can not issue org stipends to orgs that are part of any government. This includes public universities, government research institutions, etc.
94 |
95 | No.
96 |
97 | ### Anything else we should know? (optional)
98 |
99 | > Must be less than or equal to 500 characters.
100 |
101 | N/A
102 |
103 | * * *
104 |
105 | ## Profile Information
106 |
107 | > Information for the GSoC profile.
108 |
109 | ### Name
110 |
111 | stdlib
112 |
113 | ### Website URL
114 |
115 | https://stdlib.io
116 |
117 | ### Upload logo
118 |
119 | > 24-bit PNG, minimum height of 256 pixels.
120 |
121 | https://github.com/stdlib-js/google-summer-of-code/blob/main/organization/applications/logo.png
122 |
123 | ### Tagline
124 |
125 | > A very short description of your organization. Must be less than or equal to 50 characters.
126 |
127 | The fundamental numerical library for JavaScript
128 |
129 | ### Primary open source license
130 |
131 | > The open source license that your organization uses.
132 |
133 | Apache-2.0
134 |
135 | ### What year was your project started?
136 |
137 | 2016
138 |
139 | ### Link to your source code location
140 |
141 | https://github.com/stdlib-js/stdlib
142 |
143 | ### Organization categories
144 |
145 | > Select which categories fit your organization best. You may select up to 2 categories. This helps GSoC contributors filter the large list of organizations by their interests.
146 |
147 | - [ ] Artificial intelligence
148 | - [x] Data (databases, analytics, visualization, AI/ML, etc)
149 | - [ ] Development tools (version control systems, CICD tools, text editors, issue managers, q/a tools, etc)
150 | - [ ] End user applications
151 | - [ ] Infrastructure and cloud (hardware, software defined infrastructure, cloud native tooling, orchestration and automation, etc)
152 | - [ ] Media (graphics, video, audio, VR, streaming, gaming, content management, etc)
153 | - [ ] Operating systems
154 | - [ ] Programming languages (libraries, package managers, testing tools, etc)
155 | - [x] Science and medicine (healthcare, biotech, life sciences, academic research, etc)
156 | - [ ] Security (tools and frameworks)
157 | - [ ] Social and communications (Blog, chat, forums, wikis, etc)
158 | - [ ] Web (tools and frameworks)
159 | - [ ] Other
160 |
161 | ### Organization technologies
162 |
163 | > Enter up to 5 keywords for the primary specific technologies your organization uses. Examples: Python, Javascript, MySQL, Hadoop, OpenGL, Arduino.
164 |
165 | JavaScript, Node.js, C, TypeScript
166 |
167 | ### Organization topics
168 |
169 | > Enter keywords for general topics that describe your organization. Examples: Robotics, Cloud, Graphics, Web, etc. Select up to 5.
170 |
171 | Scientific Computing, Mathematics, Statistics, Numerical Computing, Web
172 |
173 | ### Organization description
174 |
175 | > Describe what it is your organization does. This information will also be included in the archive once the program has ended.
176 |
177 | stdlib is a standard library for JavaScript and Node.js with an emphasis on numerical and scientific computing applications. The project aims to provide functionality similar to NumPy and SciPy for use in JavaScript environments with special consideration for the unique constraints and opportunities afforded by the Web. stdlib is primarily written in JavaScript, C, and Fortran.
178 |
179 | ### Contributor guidance
180 |
181 | > Provide your potential contributors with a page containing tips on how to write a successful proposal for your organization. Let them know what you want included, how you want it structured, and how to best get in touch.
182 |
183 | https://github.com/stdlib-js/google-summer-of-code
184 |
185 | ### Direct Communication methods
186 |
187 | > How do you want potential contributors to interact with your organization and mentors? Chat clients such as IRC, Zulip or Rocket Chat are very well suited to Google Summer of Code collaboration and are recommended. But email or other methods are also acceptable. Choose communications options from the dropdown below. One email or chat method required.
188 |
189 | chat; https://gitter.im/stdlib-js/stdlib
190 |
191 | ### Social Communication Methods
192 |
193 | > Social platforms for bi-directional communications can be useful in getting input from potential contributors. Choose social channel options from the dropdown below.
194 |
195 | Twitter; https://twitter.com/stdlibjs
196 |
--------------------------------------------------------------------------------
/organization/applications/2025.md:
--------------------------------------------------------------------------------
1 |
6 |
7 | # Application
8 |
9 | > Google Summer of Code organization application for 2025.
10 |
11 | **Note**: do not use any markup in this document in order to make it easier to copy and paste answers into the official application document.
12 |
13 | Each answer must **not** exceed 1000 characters.
14 |
15 | ## Questionnaire
16 |
17 | ### Why does your organization want to participate in Google Summer of Code (GSoC)?
18 |
19 | First and foremost, we want to leverage GSoC as an opportunity to grow our community and introduce new contributors to open source. While we realize that many contributors will move on to other endeavors after GSoC is over, our hope is that some GSoC contributors will find a home in the stdlib community, continue contributing to the project, and eventually join the stdlib core development team where they'll have a direct hand in shaping the future of open source.
20 |
21 | Second, GSoC gives new contributors an opportunity to be paid to work on stdlib--an opportunity that most core stdlib developers do not have--and gives stdlib the opportunity to pursue projects which are of fundamental importance but lack sufficient people power to bring to completion.
22 |
23 | ### What would your organization consider to be a successful GSoC program?
24 |
25 | We want contributors to take on projects which are important to stdlib and to implement them successfully, thus improving stdlib. A successful program is thus one in which (a) GSoC contributors are having fun, learning, and feeling excited about their work, (b) GSoC contributors have, on average, at least one merged pull request every week, (c) GSoC contributors continue interacting with our community outside of their project and continue contributing after the program is over, and (d) the stdlib community benefits from the conversations, new perspectives, and unique talents that each GSoC contributor will bring while working on projects of fundamental importance.
26 |
27 | ### How will you keep mentors engaged with their GSoC contributors?
28 |
29 | Most stdlib mentors have either mentored as part of GSoC or elsewhere or were GSoC contributors in the past. We require that mentors be existing contributors to stdlib and be familiar with both the code and the project area. We further require that mentors and contributors interact and communicate publicly in order to encourage participation from the greater stdlib community. And lastly, we require that mentors and contributors meet at least once a week to discuss their project, preferably via video conferencing, and we strongly encourage that mentors pair program with contributors at least once every two weeks.
30 |
31 | Each project will have one or more backup or co-mentors, and no mentor is allowed to be a primary mentor for more than one project, or a backup or co-mentor for more than two projects. This may require taking fewer slots than we would like, but we believe this is better than stretching our mentoring capacity too thin and risking mentor burn out.
32 |
33 | ### How will you help your GSoC contributors stay on schedule to complete their projects?
34 |
35 | By holding weekly developer stand-ups, weekly 1-on-1s, and bi-weekly pair programming sessions, one of our primary goals will be to notice, as early as possible, when a contributor is struggling. Early identification of problems or potential slippages will allow us to quickly provide the support and resources a contributor needs to succeed and overcome encountered problems. We anticipate that, in most cases, if a contributor is struggling, a project's timeline will be found to be unrealistic or require modification due to, e.g., unforeseen technical challenges.
36 |
37 | If a contributor continues to struggle despite increased mentor support, we'll give a contributor a reasonable, mutually agreed upon set of goals to achieve in 1-2 weeks. If the contributor begins making sufficient progress (with our help), we will pass the contributor. Otherwise, we will fail the contributor.
38 |
39 | ### How will you get your GSoC contributors involved in your community during GSoC?
40 |
41 | Establishing a habit of open communication is vital for open source participation. We strongly encourage that all contributors participate in stdlib's weekly public office hours and that mentor-contributor interactions happen on a public channel, such as our public Element channel or on GitHub. By encouraging public participation and communication, members of the greater stdlib community have opportunities to take part in project discussions, engage in community review, and provide feedback.
42 |
43 | GSoC contributors will also be encouraged to blog about their progress at least once every two weeks. Blogs will be aggregated on a public wiki. We will further encourage GSoC contributors to help triage issues and review other pull requests, which is an excellent way to get involved in the stdlib community.
44 |
45 | ### Anything else we should know? (optional)
46 |
47 | N/A
48 |
49 | ### Is your organization part of any government? (yes or no)
50 |
51 | No.
52 |
53 | ### GSoC Reference Contact? (optional)
54 |
55 | > If you are an organization that has not been accepted into GSoC before, is there a Google employee or a veteran GSoC organization who will vouch for you? If so, please enter their name, contact email, relationship to your organization, and their role (Google employee, org admin of XX org, etc.)
56 |
57 | N/A
58 |
59 | * * *
60 |
61 | ## Organization Application
62 |
63 | ### Ideas List
64 |
65 | > Provide the URL for your organization's curated Ideas List for 2025. This is very important: Prospective GSoC Contributors will view this link to understand the kinds of projects available in your organization. A clean and simple presentation is best. Avoid links to unfiltered bug trackers or other specialized tools.
66 |
67 | https://github.com/stdlib-js/google-summer-of-code/blob/main/ideas.md
68 |
69 | ### Mentors (number)
70 |
71 | > How many Mentors does your Organization have available to participate in this program? (This is the number of people listed in our mentor document: .)
72 |
73 | 11
74 |
75 | ### Program Retention Survey
76 |
77 | > The last program your organization participated in was:
78 |
79 | 2024
80 |
81 | #### Number of accepted students/GSoC contributors? (number)
82 |
83 | 4
84 |
85 | #### Number of participants who are still active today? (number)
86 |
87 | 4
88 |
89 | ### Is your organization part of any government? (yes or no)
90 |
91 | > This will not affect your selection into the program. However, as stated in the Program Rules, we can not issue org stipends to orgs that are part of any government. This includes public universities, government research institutions, etc.
92 |
93 | No.
94 |
95 | ### Anything else we should know? (optional)
96 |
97 | > Must be less than or equal to 500 characters.
98 |
99 | N/A
100 |
101 | * * *
102 |
103 | ## Profile Information
104 |
105 | > Information for the GSoC profile.
106 |
107 | ### Name
108 |
109 | stdlib
110 |
111 | ### Website URL
112 |
113 | https://stdlib.io
114 |
115 | ### Upload logo
116 |
117 | > 24-bit PNG, minimum height of 256 pixels.
118 |
119 | https://github.com/stdlib-js/google-summer-of-code/blob/main/organization/applications/logo.png
120 |
121 | ### Tagline
122 |
123 | > A very short description of your organization. Must be less than or equal to 50 characters.
124 |
125 | The fundamental numerical library for JavaScript
126 |
127 | ### Primary open source license
128 |
129 | > The open source license that your organization uses.
130 |
131 | Apache-2.0
132 |
133 | ### What year was your project started?
134 |
135 | 2016
136 |
137 | ### Link to your source code location
138 |
139 | https://github.com/stdlib-js/stdlib
140 |
141 | ### Organization categories
142 |
143 | > Select which categories fit your organization best. You may select up to 2 categories. This helps GSoC contributors filter the large list of organizations by their interests.
144 |
145 | - [ ] Artificial intelligence
146 | - [x] Data (databases, analytics, visualization, AI/ML, etc)
147 | - [ ] Development tools (version control systems, CICD tools, text editors, issue managers, q/a tools, etc)
148 | - [ ] End user applications
149 | - [ ] Infrastructure and cloud (hardware, software defined infrastructure, cloud native tooling, orchestration and automation, etc)
150 | - [ ] Media (graphics, video, audio, VR, streaming, gaming, content management, etc)
151 | - [ ] Operating systems
152 | - [ ] Programming languages (libraries, package managers, testing tools, etc)
153 | - [x] Science and medicine (healthcare, biotech, life sciences, academic research, etc)
154 | - [ ] Security (tools and frameworks)
155 | - [ ] Social and communications (Blog, chat, forums, wikis, etc)
156 | - [ ] Web (tools and frameworks)
157 | - [ ] Other
158 |
159 | ### Organization technologies
160 |
161 | > Enter up to 5 keywords for the primary specific technologies your organization uses. Examples: Python, Javascript, MySQL, Hadoop, OpenGL, Arduino.
162 |
163 | JavaScript, Node.js, C, TypeScript, WebAssembly
164 |
165 | ### Organization topics
166 |
167 | > Enter keywords for general topics that describe your organization. Examples: Robotics, Cloud, Graphics, Web, etc. Select up to 5.
168 |
169 | Scientific Computing, Mathematics, Statistics, Numerical Computing, Web
170 |
171 | ### Organization description
172 |
173 | > Describe what it is your organization does. This information will also be included in the archive once the program has ended.
174 |
175 | stdlib is a standard library for JavaScript and Node.js with an emphasis on numerical and scientific computing applications. The project aims to provide functionality similar to NumPy and SciPy for use in JavaScript environments with special consideration for the unique constraints and opportunities afforded by the Web. stdlib is primarily written in JavaScript, C, and Fortran.
176 |
177 | ### Contributor guidance
178 |
179 | > Provide your potential contributors with a page containing tips on how to write a successful proposal for your organization. Let them know what you want included, how you want it structured, and how to best get in touch.
180 |
181 | https://github.com/stdlib-js/google-summer-of-code
182 |
183 | ### Direct Communication methods
184 |
185 | > How do you want potential contributors to interact with your organization and mentors? Chat clients such as IRC, Zulip or Rocket Chat are very well suited to Google Summer of Code collaboration and are recommended. But email or other methods are also acceptable. Choose communications options from the dropdown below. One email or chat method required.
186 |
187 | chat; https://gitter.im/stdlib-js/stdlib
188 |
189 | ### Social Communication Methods
190 |
191 | > Social platforms for bi-directional communications can be useful in getting input from potential contributors. Choose social channel options from the dropdown below.
192 |
193 | X; https://x.com/stdlibjs
194 |
--------------------------------------------------------------------------------
/organization/applications/logo.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/stdlib-js/google-summer-of-code/3c1842d0e3c9620c8a4cc2754fbe82b65f3a6481/organization/applications/logo.png
--------------------------------------------------------------------------------
/organization/scripts/acceptance_emails.js:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env node
2 |
3 | /**
4 | * @license Apache-2.0
5 | *
6 | * Copyright (c) 2024 The Stdlib Authors.
7 | *
8 | * Licensed under the Apache License, Version 2.0 (the "License");
9 | * you may not use this file except in compliance with the License.
10 | * You may obtain a copy of the License at
11 | *
12 | * http://www.apache.org/licenses/LICENSE-2.0
13 | *
14 | * Unless required by applicable law or agreed to in writing, software
15 | * distributed under the License is distributed on an "AS IS" BASIS,
16 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
17 | * See the License for the specific language governing permissions and
18 | * limitations under the License.
19 | */
20 |
21 | 'use strict';
22 |
23 | // MODULES //
24 |
25 | var resolve = require( 'path' ).resolve;
26 | var mustache = require( 'mustache' );
27 | var mkdirp = require( 'mkdirp' ).sync;
28 | var readFile = require( '@stdlib/fs-read-file' ).sync;
29 | var writeFile = require( '@stdlib/fs-write-file' ).sync;
30 | var currentYear = require( '@stdlib/time-current-year' );
31 | var format = require( '@stdlib/string-format' );
32 | var ENV = require( '@stdlib/process-env' );
33 | var parseCSV = require( './parse_csv.js' );
34 |
35 |
36 | // VARIABLES //
37 |
38 | var SENDER = ENV[ 'SENDER' ];
39 | var NUM_APPS = parseInt( ENV[ 'NUM_APPS' ], 10 );
40 | var BONDING_START = ENV[ 'BONDING_START' ];
41 | var BONDING_STOP = ENV[ 'BONDING_STOP' ];
42 | var ORG_ADMIN = ENV[ 'ORG_ADMIN' ];
43 | var ORG_ADMIN_EMAIL = ENV[ 'ORG_ADMIN_EMAIL' ];
44 |
45 | var FOPTS = {
46 | 'encoding': 'utf8'
47 | };
48 |
49 | var tpath = resolve( __dirname, '..', 'templates', 'acceptance.md' );
50 | var TMPL = readFile( tpath, FOPTS );
51 |
52 | var dpath = resolve( __dirname, 'tmp', 'accepted.csv' );
53 | var DATA = parseCSV( readFile( dpath, FOPTS ) );
54 |
55 | var SUBJECT = format( '[GSoC %d] Congratulations! Your stdlib proposal was accepted!', currentYear() );
56 |
57 |
58 | // FUNCTIONS //
59 |
60 | /**
61 | * Returns an object containing template parameters.
62 | *
63 | * @private
64 | * @returns {Object} template parameter object
65 | */
66 | function params() {
67 | return {
68 | 'first_name': '',
69 | 'number_of_applications': NUM_APPS,
70 | 'bonding_start_date': BONDING_START,
71 | 'bonding_stop_date': BONDING_STOP,
72 | 'org_admin': ORG_ADMIN,
73 | 'org_admin_email': ORG_ADMIN_EMAIL,
74 | 'sender_name': SENDER,
75 | 'mentors': ''
76 | };
77 | }
78 |
79 |
80 | // MAIN //
81 |
82 | /**
83 | * Main execution sequence.
84 | *
85 | * @private
86 | * @throws {Error} unexpected error
87 | */
88 | function main() {
89 | var opath;
90 | var opts;
91 | var dir;
92 | var err;
93 | var txt;
94 | var v;
95 | var t;
96 | var i;
97 |
98 | dir = resolve( __dirname, 'tmp', 'accepted' );
99 | mkdirp( dir );
100 |
101 | for ( i = 0; i < DATA.length; i++ ) {
102 | v = DATA[ i ];
103 |
104 | opts = params();
105 | opts.first_name = v.first_name;
106 | opts.mentors = v.mentor_1 + ' and ' + v.mentor_2;
107 |
108 | t = mustache.render( TMPL, opts );
109 |
110 | txt = [
111 | 'E-mail: ' + v.e_mail,
112 | 'Subject: ' + SUBJECT,
113 | '',
114 | t
115 | ];
116 | opath = resolve( dir, v.first_name + '_' + v.last_name + '.txt' );
117 | err = writeFile( opath, txt.join( '\n' ), FOPTS );
118 | if ( err ) {
119 | throw err;
120 | }
121 | }
122 | }
123 |
124 | main();
125 |
--------------------------------------------------------------------------------
/organization/scripts/announcement.js:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env node
2 |
3 | /**
4 | * @license Apache-2.0
5 | *
6 | * Copyright (c) 2024 The Stdlib Authors.
7 | *
8 | * Licensed under the Apache License, Version 2.0 (the "License");
9 | * you may not use this file except in compliance with the License.
10 | * You may obtain a copy of the License at
11 | *
12 | * http://www.apache.org/licenses/LICENSE-2.0
13 | *
14 | * Unless required by applicable law or agreed to in writing, software
15 | * distributed under the License is distributed on an "AS IS" BASIS,
16 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
17 | * See the License for the specific language governing permissions and
18 | * limitations under the License.
19 | */
20 |
21 | 'use strict';
22 |
23 | // MODULES //
24 |
25 | var resolve = require( 'path' ).resolve;
26 | var mustache = require( 'mustache' );
27 | var mkdirp = require( 'mkdirp' ).sync;
28 | var readFile = require( '@stdlib/fs-read-file' ).sync;
29 | var writeFile = require( '@stdlib/fs-write-file' ).sync;
30 | var ENV = require( '@stdlib/process-env' );
31 | var parseCSV = require( './parse_csv.js' );
32 |
33 |
34 | // VARIABLES //
35 |
36 | var SENDER = ENV[ 'SENDER' ];
37 | var NUM_APPS = parseInt( ENV[ 'NUM_APPS' ], 10 );
38 | var CODING_START = ENV[ 'CODING_START' ];
39 |
40 | var FOPTS = {
41 | 'encoding': 'utf8'
42 | };
43 |
44 | var tpath = resolve( __dirname, '..', 'templates', 'announcement.md' );
45 | var TMPL = readFile( tpath, FOPTS );
46 |
47 | var dpath = resolve( __dirname, 'tmp', 'accepted.csv' );
48 | var DATA = parseCSV( readFile( dpath, FOPTS ) );
49 |
50 |
51 | // FUNCTIONS //
52 |
53 | /**
54 | * Returns an object containing template parameters.
55 | *
56 | * @private
57 | * @returns {Object} template parameter object
58 | */
59 | function params() {
60 | return {
61 | 'number_of_accepted_applications': NUM_APPS,
62 | 'coding_start_date': CODING_START,
63 | 'sender_name': SENDER,
64 | 'projects': []
65 | };
66 | }
67 |
68 |
69 | // MAIN //
70 |
71 | /**
72 | * Main execution sequence.
73 | *
74 | * @private
75 | * @throws {Error} unexpected error
76 | */
77 | function main() {
78 | var opath;
79 | var opts;
80 | var dir;
81 | var err;
82 | var v;
83 | var o;
84 | var t;
85 | var i;
86 |
87 | dir = resolve( __dirname, 'tmp', 'announcement' );
88 | mkdirp( dir );
89 |
90 | opts = params();
91 | for ( i = 0; i < DATA.length; i++ ) {
92 | v = DATA[ i ];
93 | o = {};
94 | o.first_name = v.first_name;
95 | o.last_name = v.last_name;
96 | o.project_title = v.project_title;
97 | o.mentors = v.mentor_1 + ', ' + v.mentor_2;
98 | opts.projects.push( o );
99 | }
100 | t = mustache.render( TMPL, opts );
101 |
102 | opath = resolve( dir, 'announcement.txt' );
103 | err = writeFile( opath, t, FOPTS );
104 | if ( err ) {
105 | throw err;
106 | }
107 | }
108 |
109 | main();
110 |
--------------------------------------------------------------------------------
/organization/scripts/parse_csv.js:
--------------------------------------------------------------------------------
1 | /**
2 | * @license Apache-2.0
3 | *
4 | * Copyright (c) 2024 The Stdlib Authors.
5 | *
6 | * Licensed under the Apache License, Version 2.0 (the "License");
7 | * you may not use this file except in compliance with the License.
8 | * You may obtain a copy of the License at
9 | *
10 | * http://www.apache.org/licenses/LICENSE-2.0
11 | *
12 | * Unless required by applicable law or agreed to in writing, software
13 | * distributed under the License is distributed on an "AS IS" BASIS,
14 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 | * See the License for the specific language governing permissions and
16 | * limitations under the License.
17 | */
18 |
19 | 'use strict';
20 |
21 | // MODULES //
22 |
23 | var RE_EOL = require( '@stdlib/regexp-eol' ).REGEXP;
24 | var trim = require( '@stdlib/string-trim');
25 | var snakecase = require( '@stdlib/string-base-snakecase' );
26 |
27 |
28 | // VARIABLES //
29 |
30 | var SEP = ',';
31 |
32 |
33 | // MAIN //
34 |
35 | /**
36 | * Parses basic CSV to a JSON array.
37 | *
38 | * @private
39 | * @param {string} str - CSV string
40 | * @returns {Array} output array
41 | */
42 | function parse( str ) {
43 | var header;
44 | var lines;
45 | var line;
46 | var out;
47 | var o;
48 | var v;
49 | var i;
50 | var j;
51 | var k;
52 |
53 | lines = trim( str ).split( RE_EOL );
54 |
55 | header = lines[ 0 ].split( SEP );
56 | for ( i = 0; i < header.length; i++ ) {
57 | header[ i ] = snakecase( header[ i ] );
58 | }
59 | out = [];
60 | for ( i = 1; i < lines.length; i++ ) {
61 | line = lines[ i ].split( SEP );
62 | o = {};
63 | for ( j = 0; j < line.length; j++ ) {
64 | k = header[ j ];
65 | v = line[ j ];
66 | if ( v === 'TRUE' ) {
67 | v = true;
68 | } else if ( v === 'FALSE' ) {
69 | v = false;
70 | }
71 | o[ k ] = v;
72 | }
73 | out.push( o );
74 | }
75 | return out;
76 | }
77 |
78 |
79 | // EXPORTS //
80 |
81 | module.exports = parse;
82 |
--------------------------------------------------------------------------------
/organization/scripts/rejection_emails.js:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env node
2 |
3 | /**
4 | * @license Apache-2.0
5 | *
6 | * Copyright (c) 2024 The Stdlib Authors.
7 | *
8 | * Licensed under the Apache License, Version 2.0 (the "License");
9 | * you may not use this file except in compliance with the License.
10 | * You may obtain a copy of the License at
11 | *
12 | * http://www.apache.org/licenses/LICENSE-2.0
13 | *
14 | * Unless required by applicable law or agreed to in writing, software
15 | * distributed under the License is distributed on an "AS IS" BASIS,
16 | * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
17 | * See the License for the specific language governing permissions and
18 | * limitations under the License.
19 | */
20 |
21 | 'use strict';
22 |
23 | // MODULES //
24 |
25 | var resolve = require( 'path' ).resolve;
26 | var mustache = require( 'mustache' );
27 | var mkdirp = require( 'mkdirp' ).sync;
28 | var readFile = require( '@stdlib/fs-read-file' ).sync;
29 | var writeFile = require( '@stdlib/fs-write-file' ).sync;
30 | var currentYear = require( '@stdlib/time-current-year' );
31 | var ENV = require( '@stdlib/process-env' );
32 | var format = require( '@stdlib/string-format' );
33 | var parseCSV = require( './parse_csv.js' );
34 |
35 |
36 | // VARIABLES //
37 |
38 | var SENDER = ENV[ 'SENDER' ];
39 | var NUM_APPS = parseInt( ENV[ 'NUM_APPS' ], 10 );
40 | var NUM_ACCEPTED = parseInt( ENV[ 'NUM_ACCEPTED' ], 10 );
41 |
42 | var FOPTS = {
43 | 'encoding': 'utf8'
44 | };
45 |
46 | var tpath = resolve( __dirname, '..', 'templates', 'rejection.md' );
47 | var TMPL = readFile( tpath, FOPTS );
48 |
49 | var dpath = resolve( __dirname, 'tmp', 'rejected.csv' );
50 | var DATA = parseCSV( readFile( dpath, FOPTS ) );
51 |
52 | var SUBJECT = format( '[GSoC %d] Proposal notification - stdlib', currentYear() );
53 |
54 |
55 | // FUNCTIONS //
56 |
57 | /**
58 | * Returns an object containing template parameters.
59 | *
60 | * @private
61 | * @returns {Object} template parameter object
62 | */
63 | function params() {
64 | return {
65 | 'first_name': '',
66 | 'number_of_applications': NUM_APPS,
67 | 'number_of_accepted_applications': NUM_ACCEPTED,
68 | 'merged_patch': false,
69 | 'unmerged_patch': false,
70 | 'sender_name': SENDER
71 | };
72 | }
73 |
74 |
75 | // MAIN //
76 |
77 | /**
78 | * Main execution sequence.
79 | *
80 | * @private
81 | * @throws {Error} unexpected error
82 | */
83 | function main() {
84 | var opath;
85 | var opts;
86 | var dir;
87 | var err;
88 | var txt;
89 | var v;
90 | var t;
91 | var i;
92 |
93 | dir = resolve( __dirname, 'tmp', 'rejected' );
94 | mkdirp( dir );
95 |
96 | for ( i = 0; i < DATA.length; i++ ) {
97 | v = DATA[ i ];
98 |
99 | opts = params();
100 | opts.first_name = v.first_name;
101 | if ( v.landed_patch ) {
102 | opts.merged_patch = true;
103 | } else if ( v.submitted_patch ) {
104 | opts.unmerged_patch = true;
105 | }
106 | t = mustache.render( TMPL, opts );
107 |
108 | txt = [
109 | 'E-mail: ' + v.e_mail,
110 | 'Subject: ' + SUBJECT,
111 | '',
112 | t
113 | ];
114 | opath = resolve( dir, v.first_name + '_' + v.last_name + '.txt' );
115 | err = writeFile( opath, txt.join( '\n' ), FOPTS );
116 | if ( err ) {
117 | throw err;
118 | }
119 | }
120 | }
121 |
122 | main();
123 |
--------------------------------------------------------------------------------
/organization/slot_announcement_checklist.md:
--------------------------------------------------------------------------------
1 |
6 |
7 | # Slot Announcement Checklist
8 |
9 | > A checklist of tasks which should be performed once Google informs organizations their slot allocations.
10 |
11 | ## Pre-public announcement
12 |
13 | Once Google privately notifies organizations of their slot allocation in advance of the public announcement, we need to do the following:
14 |
15 | - [ ] Ensure Google sheets databases containing the list of rejected and accepted applicants are up-to-date. You'll want to ensure that names are cleaned up (e.g., free of extraneous spaces) and that recorded contributions are current.
16 |
17 | - [ ] Save the rejected and accepted sheets as CSV files (`rejected.csv` and `accepted.csv`) in a `organization/scripts/tmp` folder.
18 |
19 | - [ ] Review the templates for the public announcement and rejection and acceptance e-mails.
20 |
21 | - [ ] Run the scripts for generating e-mail and announcement content. E.g.,
22 |
23 | ```bash
24 | $ SENDER=Athan NUM_APPS=99 NUM_ACCEPTED=5 node ./organization/scripts/rejection_emails.js
25 |
26 | $ SENDER=Athan NUM_APPS=99 BONDING_START="May 8" BONDING_STOP="June 1" ORG_ADMIN="Philipp Burckhardt" ORG_ADMIN_EMAIL="philipp.burckhardttc@gmail.com" node ./organization/scripts/acceptance_emails.js
27 |
28 | $ SENDER=Athan NUM_APPS=5 CODING_START="June 2" node ./organization/scripts/announcement.js
29 | ```
30 |
31 | - [ ] Draft a [blog post](https://github.com/stdlib-js/blog-drafts) announcing stdlib's GSoC participation, along with the selected projects.
32 |
33 | - [ ] Create a new team on the stdlib GitHub organization named `gsoc-YYYY`.
34 |
35 | - [ ] Create private `gsoc-YYYY` and `gsoc-mentors-YYYY` Slack channels.
36 |
37 | ## Post-public announcement
38 |
39 | After Google has publicly announced slot allocations, we need to do the following:
40 |
41 | > [!NOTE]
42 | > Currently, sending out acceptance e-mails is done manually. We should investigate doing this directly from Google Sheets by creating a [mail merge](https://developers.google.com/apps-script/samples/automations/mail-merge).
43 |
44 | - [ ] Post the drafted announcement to Gitter.
45 | - [ ] Sent acceptance e-mails to all accepted GSoC contributors.
46 | - [ ] Send rejection e-mails to all rejected GSoC contributors.
47 | - [ ] Invite accepted GSoC contributors to the stdlib Slack.
48 | - [ ] Invite accepted GSoC contributors to the stdlib GitHub organization and add them to the `gsoc-YYYY` team.
49 | - [ ] Add accepted GSoC mentors and contributors to the stdlib `gsoc-YYYY` Slack channel.
50 | - [ ] Add GSoC mentors to the stdlib `gsoc-mentors-YYYY` Slack channel.
51 | - [ ] Add GSoC mentors to the `gsoc-YYYY` team on GitHub.
52 | - [ ] Add accepted GSoC mentors and contributors to the stdlib GSoC calendar and have them post their planned vacations and school/obligation dates.
53 | - [ ] Arrange a kickoff call to occur within 10 days of the public announcement.
54 | - [ ] Establish a cadence for a weekly GSoC standup which should commence the first week of the coding period and should last for the entire duration of the GSoC program.
55 | - [ ] Have mentors establish weekly recurring 1:1s with GSoC contributors.
56 | - [ ] Publish the draft blog post the stdlib blog.
57 | - [ ] Cross-post blog post to other distribution channels (e.g., dev.to, Hashnode, LinkedIn).
58 | - [ ] Close all [proposals](https://github.com/stdlib-js/google-summer-of-code/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen%20label%3Arfc) on the stdlib Google Summer of Code repository.
59 |
60 | * * *
61 |
62 | ## License
63 |
64 | Reuse and redistribution of the materials in this directory (and its descendant directories) is **not** permitted without the express written consent of The Stdlib Authors.
65 |
--------------------------------------------------------------------------------
/organization/templates/acceptance.md:
--------------------------------------------------------------------------------
1 | Hello {{first_name}},
2 |
3 | Congratulations! Your Google Summer of Code application to stdlib has been accepted.
4 |
5 | You have been selected from many very high quality applications (~{{number_of_applications}}).
6 |
7 | One very important question first: do you accept the project?
8 |
9 | Often applicants apply to many internships. It is not uncommon for a GSoC project to be accepted, only to be withdrawn a couple weeks later due to an applicant accepting a different internship. We'd like to avoid this scenario, as it would likely lead us to lose a slot, despite rejecting other high quality proposals. So if you could please confirm your acceptance now, we'd greatly appreciate it!
10 |
11 | Assuming your acceptance, your official mentors are {{mentors}}. We'll be arranging a joint welcome session to welcome you to the project and facilitate introductions. After the welcome session, your mentors will contact you to discuss a schedule for you to meet and discuss your progress throughout the summer. Note that some of these mentors may act as primary mentors, and others may act only as co-mentors or backup mentors. They will discuss with you the roles they will take for your project. If at any point during the summer you are not able to contact one of your mentors, please let me and {{org_admin}} ({{org_admin_email}}) know immediately.
12 |
13 | Throughout the program, we'll also aim to hold weekly stand-ups/demo sessions for you to share what you're working on and connect with other stdlib and GSoC contributors.
14 |
15 | Here is the official timeline:
16 |
17 | https://developers.google.com/open-source/gsoc/timeline
18 |
19 | GSoC projects have flexible timelines. Right now your project is set to the default timeline for the project length you specified in your proposal. However, should you want/need to extend or contract your timeline, you should discuss that with your mentors, and let me know if you need to make any changes. Note that the timeline *must* follow one of these timelines https://developers.google.com/open-source/gsoc/help/project-dates.
20 |
21 | The community bonding period from {{bonding_start_date}} to {{bonding_stop_date}} begins now.
22 |
23 | http://googlesummerofcode.blogspot.com/2007/04/so-what-is-this-community-bonding-all.html
24 |
25 | You should spend this time to get up to speed with the community, and to set up regular meetings with your mentors for the coming months. We'll be inviting you to our internal Slack channel shortly so you can connect with mentors and other maintainers more directly.
26 |
27 | Feel free to get a head start during the bonding period, too. If you have obligations, such as examinations during this period, please let us know now.
28 |
29 | If you have any problems/questions, please don't hesitate to email me directly at any time.
30 |
31 | Once again, congratulations! We're very much looking forward to working with you in the months ahead.
32 |
33 | Warm regards,
34 |
35 | {{sender_name}}
36 |
--------------------------------------------------------------------------------
/organization/templates/announcement.md:
--------------------------------------------------------------------------------
1 | Hello everyone!
2 |
3 | As many of you may have noticed, Google has announced the results for Google Summer of Code. We are proud to announce that {{number_of_accepted_applications}} people have been accepted to work on stdlib this year. The following projects have been accepted:
4 |
5 | Contributor, Project: Mentors
6 |
7 | {{#projects}}
8 | {{first_name}} {{last_name}}, "{{project_title}}". Mentors: {{mentors}}
9 |
10 | {{/projects}}
11 | Join me in congratulating them on their acceptance.
12 |
13 | I would like to thank all of the contributors who applied this year and everyone who submitted a patch. We certainly hope that you will remain a part of our community. As one inspiring success story, one of the contributors selected this year was rejected last year, but stuck with it, engaged more deeply with the community, and successfully landed a project. In short, persistence pays off!
14 |
15 | To everyone whose proposal is accepted, you should be receiving an email from your mentors shortly to discuss how you will be communicating over the summer about your project. You should meet with your mentors about once a week during the summer to go over your progress.
16 |
17 | I would also like to thank all the mentors for helping review patches and proposals. I would like all project maintainers to strongly encourage GSoC contributors to submit pull requests early and often. This will go a long way toward making sure that you don't end the summer with a ton of code written that never gets merged. Contributors should help review pull requests by other contributors, so that we don't get bogged down reviewing too much code.
18 |
19 | The GSoC coding period officially starts {{coding_start_date}} (https://developers.google.com/open-source/gsoc/timeline).
20 |
21 | This is looking to be another very productive summer for stdlib, and I'm looking forward to it!
22 |
23 | Best,
24 |
25 | {{sender_name}}
26 |
--------------------------------------------------------------------------------
/organization/templates/rejection.md:
--------------------------------------------------------------------------------
1 | Hello {{first_name}},
2 |
3 | We're sorry to inform you that your Google Summer of Code application to stdlib was not accepted this year.
4 |
5 | We received an overwhelming number of truly excellent applications (~{{number_of_applications}}). And we were blown away by the enthusiasm and interest in stdlib. Thank you for your efforts!
6 |
7 | Unfortunately, resources are limited and only {{number_of_accepted_applications}} projects were accepted. Hard choices had to be made, and many good applications had to be rejected. The rejection is based on a number of criteria, many of which you could not influence, such as the number of mentors we had available and the number of slots Google gave us. You helped us a lot just by submitting such a good application. Your efforts certainly helped raise the bar, so thanks again.
8 |
9 | We hope that you learned something new. We'd love to have you continue to be a part of our community, and any contribution you make to stdlib is very much appreciated (bug reports, participating in community forums, patches, code, etc). But, of course, we understand that you may not have time, especially if you find some other job over the summer.
10 |
11 | Nevertheless, thank you for discussing your proposal with us. If you decide to work on your project anyway, we are sure you'll find many users and people willing to help out. It's definitely something that we'd like to have in stdlib.
12 |
13 | We encourage you to try again next year. Experience has shown that students who are involved in the project early are more likely to be accepted, so, if you do plan to do this, we recommend that you continue your contributions to the project.
14 | {{#merged_patch}}
15 |
16 | We also want to thank you for all the contributions that you made recently. It really helped improve stdlib, and now you are one of the authors of stdlib. We certainly would be quite delighted if you decide to stay around.
17 | {{/merged_patch}}
18 | {{#unmerged_patch}}
19 |
20 | We also want to thank you for the patches that you submitted recently. These should really help improve stdlib. If you finish the work to get it merged, you will become one of the authors of stdlib. We certainly would be quite delighted if you decide to stay around.
21 | {{/unmerged_patch}}
22 |
23 | Thanks again and best of luck!
24 |
25 | Warm regards,
26 |
27 | {{sender_name}}
28 |
--------------------------------------------------------------------------------
/package.json:
--------------------------------------------------------------------------------
1 | {
2 | "private": true,
3 | "name": "",
4 | "version": "0.0.0",
5 | "description": "",
6 | "license": "",
7 | "author": {
8 | "name": "The Stdlib Authors",
9 | "url": "https://github.com/stdlib-js/google-summer-of-code/graphs/contributors"
10 | },
11 | "contributors": [
12 | {
13 | "name": "The Stdlib Authors",
14 | "url": "https://github.com/stdlib-js/google-summer-of-code/graphs/contributors"
15 | }
16 | ],
17 | "funding": {
18 | "type": "opencollective",
19 | "url": "https://opencollective.com/stdlib"
20 | },
21 | "main": "",
22 | "directories": {},
23 | "scripts": {},
24 | "homepage": "https://github.com/stdlib-js/google-summer-of-code",
25 | "repository": {
26 | "type": "git",
27 | "url": "git://github.com/stdlib-js/google-summer-of-code.git"
28 | },
29 | "bugs": {
30 | "url": "https://github.com/stdlib-js/google-summer-of-code/issues"
31 | },
32 | "devDependencies": {
33 | "@stdlib/fs-read-file": "^0.2.1",
34 | "@stdlib/fs-write-file": "^0.2.1",
35 | "@stdlib/process-env": "^0.2.1",
36 | "@stdlib/regexp-eol": "^0.2.1",
37 | "@stdlib/string-base-snakecase": "^0.2.1",
38 | "@stdlib/string-format": "^0.2.2",
39 | "@stdlib/string-trim": "^0.2.1",
40 | "@stdlib/time-current-year": "^0.2.2",
41 | "mkdirp": "^0.5.1",
42 | "mustache": "^4.0.0"
43 | },
44 | "keywords": [
45 | "stdlib",
46 | "stdlib-js",
47 | "stdlib.js",
48 | "js-stdlib",
49 | "stdlibjs",
50 | "standard",
51 | "std",
52 | "library",
53 | "lib",
54 | "libstd",
55 | "gsoc"
56 | ]
57 | }
58 |
--------------------------------------------------------------------------------