Contributing to Flutter - Crickets

Help General
1

I filed an issue to add a feature to Flutter, no response.
I actually implemented it myself and opened a PR, no response.

It has been a week. What should I do?

EDIT: Turns out it was only 3 days, must’ve gotten confused with another PR.

2

I’d recommend sharing the issue and PR you mentioned here

1 Like
3

It’s not a big change, it really is just extending the features of a TextTheme apply method, so you can change properties of multiple TextStyles at once

4

My apologies, turns out stuff was happening the background the entire time.

Thanks flutter team!

7

It looks like the pull request had only been opened for 3 days. The Flutter team triages pull requests once a week to assign a reviewer. Please wait a little bit longer :slight_smile:

5 Likes
8

My apologies, turns out stuff was happening the background the entire time.
Thanks flutter team!

Yeah, I got confused with another PR.

@loic-sharma Has the team thought about having their auto reply bot reply that to new contributors?

“”“Thanks for your contribution. The flutter team triages pull requests once a week to assign a reviewer. Please be patient while we take the time to…”“”

I’m thinking about ways to make contributing feel better

6 Likes
9

I like that idea - I’ll pitch it to the team at the next contributor roundtable on December 10!

7 Likes
10

Thanks again for this PR - it looks like a reviewer has been assigned :slight_smile:

For a look behind the curtains, Flutter receives a constant stream of issues and PRs and has a multi-layered team of people who intake, triage, and respond to them. These people are already juggling tons of their own work, but tend to schedule time and attention for contributions on a weekly basis, sometimes setting aside the same time slot each week to go through their issue or PR backlog. Occasionally, they are on vacation or sick and that time slot is lost for the week. Rarely, a PR genuinely slips through the cracks and a nudge is needed to bring it back to life. (This tends to happen when, by error, both parties end up thinking they are waiting on the other.)

Contributions to Flutter take time and effort, and the Flutter team deeply appreciates each person who decides to spend an evening or weekend giving back. That said, it’s probably best to assume the typical turnaround time for a PR is on the order of weeks; not days. Sometimes they’ll be faster, but often, not.

9 Likes
11

Craig thank you for your insight on PR process.

I have never personally logged a PR for Flutter, so my observations are purely from what I have read here, X and heard on Streams.

Developers put hours, days or even weeks into solving issues, they feel that they have put a lot of effort and hard work in. (they actually have)

  1. The process is very well set out here, it seems there are sometimes a last hurdle that the contributor hits. This derails the entire process and it goes into a ∞ for loop.
    Where the team can’t move forward with the PR as certain conditions, quality are not meat and the developer don’t know or understand what is missing. If there were some mechanism in place that could guide the developer where to now, what do I need to add or take away?
    I know there were recently some controversial release, I see it as developers that care about the project and want to make difference and let the project have a successful outcome. They are trying to set up process at assist and guide developers over this last hurdle.

  2. Transparency of the PR approval process: We understand that there are a limited amount of staff on any project and that many of them have to where many hats. Are there not a way that a ticketing process can be put in place? “You are number 28 in the queue…. you call will be attended to in 150 sec”.
    This will enable developers to track and know that the team are attending to the PR. Maybe just the number in the queue and not a timeframe.

In the “The Boring Flutter Development Show” there are a video on how to contribute, do you perhaps have the link to it?

Thanks to “The Team” and you that put a lot of hard work in.

I want to refer to David McClelland, Expectancy Value Theory of Motivation

12

@CraigLabenz Thank you for taking the time to reply.
Not knowing what’s going on can be a little frustrating. Knowing how it all works behind the scenes is very comforting.

Transparency of the PR approval process: We understand that there are a limited amount of staff on any project and that many of them have to where many hats. Are there not a way that a ticketing process can be put in place? “You are number 28 in the queue…. you call will be attended to in 150 sec”.

I think this would be a great idea!
Although sounds like lots of work and would flood the Github PR thread.

13

With averaging it by eye, +/-100 commits in a week, (except week of 12/24, no idea what happened there :wink:)

image
image834×445 13.4 KB

Commits over time
Commits over time1200×512 66 KB

I have no idea how you keep track of commits and don’t miss any without a type of ticketing system.

1 Like
14

It’s our magical triage system! Teams meet regularly to check all pending pull requests for their area. This is when we assign a reviewer, or, gently remind a reviewer to follow-up if needed :slight_smile:

Thanks for the suggestion! We don’t have a strict ordering of pull requests, but maybe a message like this could work: “Your pull request will be assigned a reviewer at the next team-windows triage at 10am PST on November 10th.”

4 Likes
15

A deli counter-style ticketing system would certainly be a nice experience for the end-user, though I’m sadly afraid it would be prohibitively tricky to implement. Sorting would take thought, as not all PRs are of equal urgency. (A community contribution to a P1 should probably cut in line over a P4, for example. If not, we’ve defined the priority system on the wrong criteria.) This makes me skeptical that the Flutter team could keep the promise implied by a certain ticket number, and I think periodically breaking that promise would do more harm than good.

Secondly, many tickets are a back-and-forth process. Being “in the queue” is one thing, but what happens when a team member replies and asks for changes? Presumably, that PR shouldn’t go to the back of the line, but neither really should it stay in exactly the front? The status quo - again, highly variable on each person’s workflow - is probably that it sits idle until a GitHub notification indicates the contributor has responded, and then the reviewer will revisit again when their next “issues and PRs evaluation” time slot comes up. This, too, makes a reviewer’s progress through their personal queue irregular and hard to predict.

I’m very, very sympathetic toward the experience of folks who pour their free time into Flutter, only to feel like the effort is not valued or wanted. I will keep my thinking hat on for how we can best avoid ever creating that perception - though I do think some of the solution is expectation management (which is what Loïc and I have been talking a bit about :slight_smile:).

4 Likes