Quick summary: it should be enough for any reader wanting to know what their responsibilities are (and to read the related notes) to check their role descriptions under Phase-independent responsibilities and Current phase.
This document lists the responsibilities, related instructions and guidelines for a GSoC program. GSoC is made up of multiple phases, each of which have different responsibilities. This document is structured accordingly. Phase-independent responsibilities are listed, then phase-dependent responsibilities are divided into whether it’s the current phase, a previous phase, or an upcoming phase. Between phases, the GSoC team roles, membership and responsibilities are variant. The rest of the document is under the Details section, which holds guides, links and instructions, and it’s linked as needed from the responsibility lists.
Starts 2023-04-04, ends 2023-04-27.
| Role | Assignees |
|---|---|
| Owner (aka Admin) | Dominykas |
| Candidate helper | Anish, Rajat, Dominykas |
| Mentor | Anyone that’s a mentor in a GSoC project idea |
Starts 2023-03-20, ends 2023-04-04.
| Role | Assignees |
|---|---|
| Owner (aka Admin) | Dominykas |
| Candidate greeter/helper | Anish, Rajat, Dominykas |
Performed in two passes. First pass is that the spammy or obviously unfitting proposals are filtered out. Likely performed by the owner. Second pass is where the mentors evaluate proposals for the projects they are mentoring, and those who interacted with the candidates evaluate the candidates. All of this is done in the final review spreadsheet. The final rankings are derived by sorting the approved proposals on their scores and their authors’ (candidates’) scores.
In the second pass, each proposal for a given project idea has the same three reviewers. Two of them are the project idea’s mentors. The third is another member of the team, preferably someone with an outside perspective on the project idea. The reviewers for candidates are assigned based on who interacted most with them on the issue tracker.
Effort is put in so that the workload distribution between the proposal reviewers is equal-ish and/or practical.
The final review consists of reviewing each candidate and each proposal. That is done in two separate sheets within the final review spreadsheet. See detailed instructions below.
The primary mentor for a project is responsible for getting the project’s draft proposals reviewed. Primary mentors are encouraged to delegate part of their work to the secondary mentors, but, until that’s coordinated, the primary mentor is responsible for the proposal getting reviewed. Motivation for this rule is to prevent someone expecting the other mentor to step up without solicitation and thus resulting in delayed reviews.
Who is currently responsible for a review is tracked in the tracking spreadsheet.
This spreadsheet gets a row added automatically for every draft proposal submitted via our submission form. It also tracks whether a review is pending, who is responsible for a pending review, and who and when reviewed a given proposal. Respective mentors are expected to keep all of this up-to-date.
Do not remove rows from the spreadsheet. You might be tempted to do this for multiple review requests for the same person, but that would impede admin’s ability to track the submit-review process: for example, the admin needs to know if certain proposals are waiting for a review for a long time, and if all but the most recent are removed, the admin doesn’t know when it was first submitted; if you remove all but the oldest, the admin doesn’t know that the candidate is making repeated review requests.
Suggested process:
Example in our Matrix General channel:
Welcome @practicat, @Joangie Marquez, @Mayank Arya, @shantanu oak, @krishav 👋 If you're here for GSoC, don't forget to check out our [GSoC candidate guide](https://wiki.mathesar.org/en/community/mentoring/applicant-guide). If something is not clear, reach out!
A few things to keep in mind
We aim to greet and help new contributors (mostly GSoC candidates) multiple times per day (between all of us, not each). This schedule should act as a very rough guide, in practice we’ll often respond whenever we see a new message, but in case that’s inconvenient, use this schedule as a guide for when to perform this task.
| Member | Approximate time |
|---|---|
| Dominykas | UTC 11:00 |
| Anish | UTC 4:30 |
| Rajat | UTC 4:30 |
Related conversation thread.
Office hours are public sync meetings we host where community members (GSoC candidates mostly) join to get help. Previous year such meetings only received community participation just before the end of the proposal period. We’re currently planning to host these only during the last week of the proposal period.
We track community events, including office hours, on this Wiki page and GSoC-related events in our GSoC Calendar.
This rule should not be always applied. Its purpose is to maximize the number of issues candidates have available. Useful when number of issues available for candidates to prove themselves is low.
No-early-issue-assigns rule means that a contributor can be assigned to an issue only when he has a PR that reached some kind of completion (merged or killed).
See this conversation thread for the edge case this opens up where multiple PRs for the same issue compete to be merged
This Google calendar is used to track GSoC-related deadlines and related tasks.
GSoC administration involves periodic process reviews and reports. They are scheduled in the calendar. This thread tracks resulting updates: https://github.com/centerofci/mathesar/issues/2733
Here we collect insights gained that might be useful during future programs:
Sean
- PR reviews
- We could do a retrospective of GSoC at the end of GSoC (end of summer)
- Feels cynical
- Example
- 4 PRs for a single issue
- 3 team members left 15 comments across them
- at the end Sean submitted a PR himself
- took him 1 hour and Pavish didn't have critique
- Hasn't seen the rewards of GSoC
- Feels like a competitive classroom
- As opposed to a community
- GSoC sucks all of the good first issues
- Makes them unavailable to contributors from outside GSoC
- What are we open to considering changing (next year)?
- Are there other ways we could evaluate candidates?
- Ranking/scoring needs improvement, but went smoother than contributions
Kriti
- Many ways to solve candidate evaluation
- We could have a test that people have to take
- Too much core team time spent on candidates that might not be interesting
- Seen other projects not engage with people until they've done some work
- At CC
- Less noise
- Maybe GSoC is different these days
- A lot of people don't put in the minimum of effort
- People wanting to put things on their resume is not bad
- It's an exchange
- Problem is if the candidate doesn't offer anything
Anish
- Many people were trying to pump up number of PRs they had
- A single person did 7 good-first-issues
- Instead of doing more difficult issues
- Or single person doing many issues simultaneously
Mukesh
- Lack of documentation is a test for contributors
- A lot of contributors seem to treat GSoC as competitive
- GSoC is something you can put on your resume
- There should be a progression from easy to hard issues
- For each contributor
- Maybe contributors should come up with suggestions or ideas
- Kriti: we've had bad experiences with this
- GSoC candidates are often on Windows
- Causes many Windows-related issues
- Distorts feedback space
- Actual users might not be on Windows
- Kriti: we should just take this into account when triaging issues
- Unequal distribution of proposals for project ideas
- Many strong proposals for the same project idea
- But many project ideas didn't get almost any proposals
Ghislaine
- Valuable contributors are those that actually want to add new features
- They care
- Sean:
- 1 contributor on frontend that didn't come from GSoC
Survey
- What percentage of time each of us spent on GSoC during the proposal phase?
- Sean 60%
- Pavish 50%
- Kriti 20%
- Mukesh 40%
- Brent 20%
- Anish 30%
- Dom 100%