├── .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 | --------------------------------------------------------------------------------