You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
***Call Stacks** Simplify call stacks by grouping library frames
14
-
***Preview** Visualize Redux actions and React Components
15
-
***Navigation** Surface applications Actions and Components so that developers can easily add breakpoints or log statements.
16
-
17
-
#### Source Map Improvements
18
-
19
-
***map minified variables** it should be possible to preview and evaluate the original variables
20
-
***step over** stepping should always take you to the next statement
21
-
***step in** should not land in a function signature or other bad location.
22
-
23
-
#### Server Stability
24
-
25
-
This goal can be summarized as, we would like the debugger to behave as expected. We want to fix edge cases where breakpoints won't be hit or stepping will not land where you would expect. Here is a [list][bpbugs] of breakpoint and stepping bugs.
26
-
27
-
### Q3 Update
28
-
29
-
#### Progress
30
-
31
-
* We released the new UI in 56. Releasing was a bigger focus than we had anticipated. Internal developers did a great job of surfacing issues with the UI (preview, breakpoints, ...).
32
-
* We focused on code health, refactoring, testing, intermittents, type coverage after releasing. The debugger is in a better place now to move forward with confidence.
33
-
* We are shipping project text search. Hubert did a fantastic job building the feature. We designed it to be like Atom/Sublime's search experience and between streaming results and all of the UI details.
34
-
* We are shipping AST breakpoints, which will keep breakpoints in the correct location on page reload.
35
-
* We are shipping async stepping, which will let users step over await expressions. Jaideep did a great job laying the foundation for additional parser and stepping features in the future.
36
-
* We shipped a server side performance fix for stepping with large call stacks. We also shipped a server side fix for ignoring redundant breakpoints when returning from a function.
37
-
38
-
#### What did not get done
39
-
40
-
* We did not improve framework features. We plan on doing this in Q4 with the help of UCOSP students.
41
-
* Async Call Stack
42
-
* Source Map Stepping
43
-
* Continue to point
44
-
* Event Listeners
45
-
46
-
#### Summary
47
-
48
-
We shipped the debugger this quarter and improved our feedback loop with internal developers.
49
-
Shipping was a big accomplishment, we probably fixed ~100 bugs big and small in June and July and we
50
-
shipped a good MVP.
51
-
52
-
We also found time to add new functionality that will set us up well in the future. Both Async stepping and ast breakpoints position us well to build new features going forward.
53
-
54
-
Looking back, it would have been good to update the roadmap at the midway point when it was
55
-
clear that we would be focusing on quality improvements over features like frameworks. Going forward,
56
-
we plan the roadmap doc when we do quarterly check ins (before, during, and at the end of quarters).
57
-
58
-
59
-
60
-
### Q3 Goals (July 1st - September 30th)
61
-
62
-
**Top Goal** add features for debugging react apps.
63
-
**Secondary Goals** improve the debugger core performance and experience and continue to invest in the community
64
-
65
-
#### Framework Improvements
66
-
67
-
***Call Stacks** Simplify call stacks by grouping library frames
68
-
***Preview** Visualize Redux actions and React Components
69
-
***Navigation** Surface applications Actions and Components so that developers can easily add breakpoints or log statements.
70
-
***Performance** Improve server pause performance for large call stacks
71
-
72
-
#### Language features
73
-
74
-
***Async Call Stack** Show async stack traces in the call stack, let developers select a frame.
75
-
***Smarter Breakpoints** Help developers add breakpoints that do not move when the code changes.
76
-
* **AST Breakpoints** Recalculate locations when the page reloads based on an AST location so that the breakpoint does not move. **Column Breakpoints** Let developers add breakpoints in different locations on the line.
77
-
***Source Map Stepping** Help developers step through their code by automatically stepping when the code is transpiled.
78
-
***Continue to point** Help developers jump to a location in the code as opposed to stepping there. It’s better to jump than it is to step :)
79
-
80
-
#### Parity Features
81
-
82
-
***Project Text Search** Let developers search the sources on the page.
83
-
***Event Listeners** Let developers jump to an active event listener.
84
-
85
-
#### Invest in the community
86
-
87
-
***Mentorship** Encourage community mentorship and leadership opportunities.
88
-
***Outreach** Reach out to schools, companies, and bootcamps to organize events.
89
-
***Growth** Help contributors find meaningful work and build relationships.
90
-
***Education** Develop resources for giving a talk, writing blog posts, or recording a screencast.
*[Following up on In Progress work](#following-up-on-in-progress-work)
10
+
*[Adding a Patch](#adding-a-patch)
11
+
*[Pushing to a branch](#pushing-to-a-branch)
12
12
13
13
### Triaging Issues
14
14
15
15
We encourage the community to help make bugs actionable, make features available,
16
-
and close stale issues. Triaging is one of the most important contributions a
16
+
and close stale issues. Triaging is one of the most important contributions a
17
17
community member can make for a projects health. Stave Klabnik's
18
18
[article][gardening] on how to be an open source gardener expresses our values.
19
19
@@ -30,12 +30,29 @@ for making bugs actionable:
30
30
31
31
#### Reviewing Stale Issues
32
32
33
-
We define *stale* as issues that are 30 days or older. Stale is often an indicator of another issue: it is unnecessary, too vague, too broad, or a low priority.
33
+
We define _stale_ as issues that are 30 days or older. Stale is often an indicator of another issue: it is unnecessary, too vague, too broad, or a low priority.
34
34
35
-
**unnecessary* - close it
36
-
**vague* - clarify the issue and make it more available
37
-
**broad* - create more focused issues, such as "add flow types to `WhyPaused` component"
38
-
**low priority* - close it and add it to the [enhancements board]
35
+
*_unnecessary_ - close it
36
+
*_vague_ - clarify the issue and make it more available
37
+
*_broad_ - create more focused issues, such as "add flow types to `WhyPaused` component"
38
+
*_low priority_ - close it and add the _icebox_ label to it.
39
+
40
+
### Prioritizing Issues
41
+
42
+
At any given point, there are too many issues in the project to realistically be able to complete them all in the near future.
43
+
44
+
We try to prioritize the issues into 3 buckets: current milestone, backlog, and icebox.
45
+
46
+
* We add issues to a milestone every two weeks that we hope to accomplish in that time frame.
47
+
* We add the _backlog_ label to issues that we would like to accomplish in the next 4 to 6 weeks.
48
+
* We add the _icebox_ label to issues that we would like to get to in the future. We also close these issues so that we can keep the issue list under control. We commit to reviewing the _icebox_ issues every six weeks and re-opening issues we hope to get to.
49
+
50
+
There will always be some issues that don't fall into these buckets.
51
+
52
+
* We have not yet investigated the issue
53
+
* We think a community member could realistically do it e.g. ui polish, code health
0 commit comments