Dart GSoC 2021 Project Ideas

A list of Google Summer of Code project ideas for Dart.

For GSoC related discussions please use the dart-gsoc group.

Potential mentors

• [email protected]
• [email protected]
• [email protected]
• [email protected]

Project Application Process

All projects assume familiarity with Dart (and sometimes Flutter). Aspiring applicants are encouraged to learn Dart and try to write some code.

Applicants are welcome to find and fix bugs in Dart or some of the packages written by the Dart team. However, getting reviews can take a long time as code owners may be busy working on new features. So instead of requiring applicants to fix a good first bug, we suggest that applicants write a working code sample relevant for the proposed project.

⚠️ TODO: Clear directions for sample code.

Do not spend too much energy on this piece of sample code, we just want to see that you can code something relevant. Be aware that we have a limited number of mentors available, and will only be able to accept a few applicants.

Applications can be submitted through the summerofcode.withgoogle.com website. Students are encouraged to submit draft proposals, ideally linking to a Google Docs with permission for mentors to comment. See also the student guide on writing a proposal.

IMPORTANT: Remember to submit final proposals before the April 13th deadline.

---

⚠️ TODO: Insert additional good ideas from our draft document.

---

Idea: SPDX license detection package

• Possible Mentor(s): [email protected]
• Difficulty: easy
• Skills: Dart programming skills; text parsing.

Description: Write a Dart package for detecting SPDX license from a LICENSE file following the SPDX License List Matching Guidelines. A goal would be properly represent the license of a package on pub.dev with an SPDX identifier. Stretch goal might be to handle LICENSE files with multiple licenses and display an SPDX license expression on pub.dev.

Getting Started Try writing a small sample program that can fetch one of the SPDX master files and print it to terminal as markdown. Don't make it too perfect, just figure out how to parse the XML. For the proposal, it would be valuable to include:

• References to relevant documentation.
• A discussion of strategies for handling complicated cases with multiple licenses in the same file.
• An API outline for the package, what does the function signatures look like?
• List of features you would consider adding? what are the stretch goals? What should be omitted to keep it simple/robust?
• How do we plan to test this? What test cases can we find? How can we become reasonably confident the implementation handles all corner cases?

---

Template for additional ideas

## **Idea:** {{title}}

 - **Possible Mentor(s)**: `{{email}}`
 - **Difficulty**: {{easy | medium | advanced}}
 - **Skills**: {{keyword}}; ...

**Description**:
{{description}}

**Getting Started**
{{how to get started; good first bugs; ideas for code samples; warm-up exercises}}

----