Skip to content

Form prioritization wg #263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 3, 2020
Merged

Form prioritization wg #263

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9918c59
The table is in the main page
spastorino Mar 24, 2020
a77e552
Add prioritization wg
spastorino Mar 24, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions content/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -71,6 +71,7 @@ Name | Status | Short
[Parallel-rustc](working-groups/parallel-rustc/) | Active | Making parallel compilation the default for rustc | [#t-compiler/wg-parallel-rustc][parallel-rustc_stream]
[Polonius](working-groups/polonius/) | Active | Exploring the integration of the "NLL 2.0"-like ["Polonius analysis"][Polonius] into rustc | [#t-compiler/wg-polonius][polonius_stream]
[Polymorphization](working-groups/polymorphization/) | Active | Implement an analysis to detect when functions can remain polymorphic during code generation. | [#t-compiler/wg-polymorphization][polymorphization_stream]
[Prioritization](working-groups/prioritization/) | Active | Triaging bugs, mainly deciding if bugs are critical (potential release blockers) or not. | [#t-compiler/wg-prioritization][prioritization_stream]
[Profile-Guided Optimization](working-groups/pgo/) | Retired | Implementing profile-guided optimization for rustc | [#t-compiler/wg-profile-guided-optimization][pgo_stream]
[RFC 2229](working-groups/rfc-2229/) | Paused | Make a closure capture individual fields of the variable rather than the entire composite variable | [#t-compiler/wg-rfc-2229][rfc-2229-stream]
[RLS 2.0](working-groups/rls-2.0/) | Active | Experimenting with a new compiler architecture tailored for IDEs | [#t-compiler/wg-rls2.0][rls20_stream]
Expand All @@ -96,6 +97,7 @@ Name | Status | Short
[learning_stream]: https://rust-lang.zulipchat.com/#narrow/stream/196385-t-compiler.2Fwg-learning
[Polonius]: https://github.com/rust-lang/polonius
[diagnostics_stream]: https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics
[prioritization_stream]: https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization

## Expert Map

Expand Down
4 changes: 2 additions & 2 deletions content/procedures/form-new-working-group.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -95,7 +95,7 @@ The basic steps to setup a working group are as follows:
then open a PR against the repository (make sure to leave a note in [`#t-compiler`][cp],
as these PRs can be easily overlooked):
- Add the working group to the table in the [main
README][README]. Feel free to put N/A for any column that doesn't
page][main_page]. Feel free to put N/A for any column that doesn't
seem to apply.
- Add a subdirectory to the [`working-groups`][working_groups] directory. You do
this by copying the [`template`]({{< relref "/working-groups/template/_index.md" >}}) directory to a
Expand All @@ -116,6 +116,6 @@ The basic steps to setup a working group are as follows:
[team_repo]: https://github.com/rust-lang/team
[team_repo_example]: https://github.com/rust-lang/team/blob/master/teams/wg-traits.toml
[check_in]:../../about/triage-meeting/
[README]: ../../
[main_page]: ../../
[template]: ../working-groups/template/_index
[working_groups]: https://github.com/rust-lang/compiler-team/tree/master/working-groups
66 changes: 66 additions & 0 deletions content/working-groups/prioritization/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
---
title: Prioritization Working Group
type: docs
---

# Prioritization Working Group
![working group status: active][status]

Triaging bugs, mainly deciding if bugs are critical (potential release blockers) or not.

- **Leads:** [@spastorino][spastorino] and [@wesleywiser][wesleywiser]

[status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge
[spastorino]: https://github.com/spastorino
[wesleywiser]: https://github.com/wesleywiser

## What is the goal of this working group?

This working group aims to accomplish the following:

- Processing 'nominations' and routing bugs to folks who can fix them
- Identifying *critical* bugs and monitoring them to ensure they are
making progress
- Identifying the agenda for compiler team triage meetings
- Critical issues that are not making progress
- Beta/Stable nominations to be backported
- Issues where bugs are nominated for needing wider discussion
- Tracking deferred things and ensuring they are picked up again
- Future compatibility warnings

## How do people bring things to the working group's attention?

If something seems "obviously criticial", people can tag it as
`P-critical` (see below). But if unclear, use `I-nominated` as today to
bring it to the group's attention.

However, as we already have problems where the "intent" of a nomination
is unclear, we may wish to consider replacing `I-nominated` with more
specific `N-*` labels that identify the reason the issue was nominated:

* `N-critical` -- nominated as a potential critical issue
* `N-compiler` -- nominated for discussion by compiler team
* `N-lang` etc

## How can I get involved?

If you are interested in getting involved in this working group, come
and say hi in the Zulip stream but mainly try to attend to our meetings
on wednesday at 6pm UTC. Check out the [Rust compiler
calendar](https://rust-lang.github.io/compiler-team/#meeting-calendar).
You can also be added to the Zulip group for the working group if you
are interested in being pinged when there are things that you may want
to be involved with.

## Process

We have our pre-triage meetings on wednesday at 6pm UTC. Check out the
[Rust compiler
calendar](https://rust-lang.github.io/compiler-team/#meeting-calendar).

- **Desired experience level:** Any
- **Relevant repositories:** [`rust-lang/rust`][rust-repo]
- **Zulip stream:** [`#t-compiler/wg-prioritization`][zulip] on Zulip

[rust-repo]: https://github.com/rust-lang/rust
[zulip]: https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization
1 change: 1 addition & 0 deletions layouts/shortcodes/checkin-schedule.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,7 @@
"Parallel Rustc",
"Polonius",
"Polymorphization",
"Prioritization",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need/want check-ins from prioritization wg?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the same doubt but ended thinking well if there's nothing to say we can skip the checkin but there may be changes to share like ... we've changed labels in this or that way, we are doing our prioritization async, at the beginning we had 50 P-high issues we now have 10 and stuff like that :). Probably a lot of things could happen at the beginning I guess long term we should remove this from here. Still not 100% sure, let me know what you think.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the right thing to do per the working group formation guidelines but I wonder if perhaps we should consider changing that. Adding this wg will bring us to 13 wgs which means, if I've done my math correctly, we'll only hear from a wg every 1.5 months. That seems like a fairly long time to find out if a wg is stalled or blocked on something and not making progress (especially if that wg is doing work that's part of our yearly goals).

Perhaps we should consider only requiring checkins from teams working toward our yearly goals? Other teams can of course make use of the announcement time at the beginning of the weekly compiler team meeting to report updates on anything happening.

(I don't feel strongly about this, it's just an idle thought I had.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no clear idea either. Another possibility is to do 3 checkins per week. Mainly given that from time to time there are some wgs with no updates to share.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think let's merge as is and discuss changing how we handle check-ins later. I also don't actually think every 1.5 months is that bad, but I do think we can do better.

"RLS 2.0",
"Self-Profile",
"Traits",
Expand Down