Skip to content
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.

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

Weekly Triage meetings: Jan–Dec 2025 #268

Open
RRosio opened this issue Jan 8, 2025 · 1 comment
Open

Weekly Triage meetings: Jan–Dec 2025 #268

RRosio opened this issue Jan 8, 2025 · 1 comment
Labels
Dev Meeting Minutes Minutes from a dev meeting.

Comments

@RRosio
Copy link

RRosio commented Jan 8, 2025

Triage issues in JupyterLab and corresponding projects.

Meeting is typically held at 09:00 US Pacific time on Tuesdays.

Meeting info: https://zoom.us/my/jovyan?pwd%3Dc0JZTHlNdS9Sek9vdzR3aTJ4SzFTQT09

Previous notes:

Goals

Act on long-running, highly demanded, or highly discussed issues to get them ready for development work.

Resources

https://jupyterlab.readthedocs.io/en/latest/developer/contributing.html#submitting-a-pull-request-contribution

Triage Process

All requested information, where applicable, is provided. From the templates in JupyterLab’s issues:

For a bug:

  • Description, preferably including screen shots
  • Steps to reproduce
  • Expected behavior
  • Context, such as OS, browser, JupyterLab version, and output or log excerpts

For a feature request:

  • Description of the problem
  • Description of the proposed solution
  • Additional context

The issue should represent real, relevant, feasible work. In short, if a knowledgeable person were to be assigned this issue, they would be able to complete it with a reasonable amount of effort and assistance, and it furthers the goals of the Jupyter project.

  • Issues should be unique; triage is the best time to identify duplicates.
  • Bugs represent valid expectations for use of Jupyter products and services.
  • Expectations for security, performance, accessibility, and localization match generally-accepted norms in the community that uses Jupyter products.
  • The issue represents work that one developer can commit to owning, even if they collaborate with other developers for feedback. Excessively large issues should be split into multiple issues, each triaged individually, or into team-compass issues to discuss more substantive changes.
  1. Read issues
  2. Tag issues
    a. good first issue
    b. bug
    c. feature parity
    d. Tag milestones
  3. Identify duplicates
  4. Respond to issues
  5. Assign another person

Add milestone if you can achieve the goal.

Meetings

Primary focus:

@RRosio RRosio added the Dev Meeting Minutes Minutes from a dev meeting. label Jan 8, 2025
@RRosio
Copy link
Author

RRosio commented Jan 8, 2025

January 7, 2024

Name Organization Username
Michał Krassowski QuanSight @krassowski
Andrii Ieroshenko AWS @andrii-i
Rosio Reyes Anaconda @RRosio
Michael Chin AWS @michaelnchin

Before the meeting, 10 issues in JupyterLab needed triage. After the meeting, none remain.

Before the meeting, 1 issue in Notebook needed triage. After the meeting, none remain.

Before the meeting, 1 issue in Notebook Classic needed triage. After the meeting, 1 remains.

Before the meeting, 1 issue in JupyterLab Desktop needed triage, after the meeting none remain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Dev Meeting Minutes Minutes from a dev meeting.
Projects
None yet
Development

No branches or pull requests

1 participant