Work prioritization and triaging

[goanpeca]

Hello ✋

I have only recently started helping on JupyterLab and it has been a very rewarding experience. I really enjoy helping, being part of the community, and seeing the project grow.

With JupyterCon imminent arrival, it seems the project is on turbo mode and some might be incurring in doing more work on different fronts and "paying a price" on it.

I think the project should have some time for:

• Work prioritization
• Issue triaging
• Vision building (there is a separate issue for that)
• Website update
• Social media and users interaction (the survey will help a lot but it is just a part of this)

For this issue, I just want to focus on Work prioritization and triaging, sure it is less fun than coding a new cool thing, but an image is worth a thousand words so:

There should probably be a separate (private?) meeting with core members only (I am definitely not including myself here) to triage things, take roadmap decisions, and keep the current work and milestones honest and real. A roadmap is not written in stone, it can be updated, some things might be left out.. it is ok to say No.

The localization work added a bunch of extra (not planned) work on some of the devs by helping me get through with it, but receiving a "No, it is not in the plan and we do not have time for it, aim for 3.1, 3.2 or 4.x" would have been also a perfectly valid and honest answer, even if it would have made me feel sad 🙃.

It has been a weird year for everyone, and JupyterCon is definitely a "special time and case", but stress, feelings of burning out and taking fewer hours of sleep are not a sign of good health in a project however specific the circumstances may be.

[afshin]

I agree that we need a separate call/thread for project management as our community call has grown. I'm not sure about the specifics of how to conduct it, how long it should be, or who should be there. But the need is apparent. Thanks for opening this issue Gonzalo.

[ellisonbg]

+1

…

On Wed, Aug 26, 2020 at 12:13 PM Afshin Taylor Darian < ***@***.***> wrote: I agree that we need a separate call/thread for project management as our community call has grown. I'm not sure about the specifics of how to conduct it, how long it should be, or who should be there. But the need is apparent. Thanks for opening this issue Gonzalo. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUGLZLLWYL5JBWG26XDSCVNHNANCNFSM4QMEUKDQ> .

-- Brian E. Granger Principal Technical Program Manager, AWS AI Platform (brgrange@amazon.com) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[goanpeca]

(Zenhub is a pretty cool tool to manage many projects across organizations and integrates seamlessly with Github https://www.zenhub.com/)

[krassowski]

I think it is a nice idea.

• Enabling integration can be challenging as ZenHub requires permissions to your repositories; I think I was not able to explain this well at the call, but in short its not a ZenHub's fault but the problem with how coarse is the GitHub permissions system, see: GitHub's Permission System is Flawed dear-github/dear-github#113
• Therefore, is it essential for contributors to use this tool?
  • (answered on the call: no, it's not - it is an opt-in)
  • my new question: is it possible for a new contributor to view the board/epics without enabling integration with ZenHub (so they do not feel left out/as having a barrier in getting into contributing)

I will also link to some features that ZenHub offers but are actually somewhat already available without third-party integrations on GitHub:

• code owners
• scheduled reminders
• projects

[goanpeca]

Thanks for the suggestions and questions @krassowski

my new question: is it possible for a new contributor to view the board/epics without enabling integration with ZenHub (so they do not feel left out/as having a barrier in getting into contributing)

It seems to require you to login (with github), but I am not sure if this means you need at give all the access to zenhub or juts login.

I am requesting on zenhub support about a public view of the board without login. See for a request that is already under consideration https://portal.productboard.com/zenhub/1-zenhub-s-roadmap/c/46-access-zenhub-without-having-github-access

---

I will also link to some features that ZenHub offers but are actually somewhat already available without third-party integrations on GitHub

code owners

Indeed we should use, this, the comments I made where about automating things and movement between pipelines based on what github already provides.

scheduled reminders

Might be useful, but this is more of a personal preference as some pointed out, more reminders would not improve things for some devs. I tend to agree with this view.

projects

Very lacking in terms of flexibility. See https://github.com/jupyterlab/jupyterlab/projects/5 for something that happened to be created for this repo.

• Projects cannot be easily filtered:
• Things need to be added to a project
• It mixes issues with "notes", which I do not find very useful, and rather confusing.
• Need to manually add cards to a column, which makes its usage rather annoying.

[goanpeca]

Additional useful actions:

• https://github.com/marketplace/actions/auto-request-review

[fcollonval]

👍 also

[goanpeca]

There is also this coming in the pipeline, which might solve of the pain points for the orgaization natively within github (no Zenhub needed :) )

https://github.com/features/issues

@afshin, @blink1073, @jasongrout maybe we could request the beta and give it a try?

[blink1073]

maybe we could request the beta

Done!

jupyterlab has been added to the new projects beta waitlist. 
Please make sure your primary email address is up to date. 

[jtpio]

cc @jweill-aws since the topic of triaging was discussed during today's weekly meeting: #128 (comment)

We could continue here in this issue, or open a new one if you think it needs a fresh start.

[JasonWeill]

As discussed during the weekly JupyterLab meeting that @jtpio mentioned above, one proposal is to automatically tag all new and existing untriaged issues with a label like needs-triage. Once the issue meets our definition of ready, we will remove the needs-triage label, making it ready to pick up.

Open questions:

• What is our definition of ready? An issue that is "ready" can be picked up and worked on with high confidence that we will accept it into the project.
• What other labels should we use, existing or not? Once a triaging user clears needs-triage, should we expect them to add any other labels?
• Who may perform triage? We want to make this process as lightweight as possible, while also guarding against cliquish behavior (e.g., a user approving their friend's or colleague's enhancement request without keeping the project's needs first in priority).

[jtpio]

@jweill-aws do you think this is now fixed by jupyterlab/jupyterlab#11660 and the new triage meeting? (#137)

[JasonWeill]

@jtpio I believe it is, although I have also been asked about promoting the triage meeting elsewhere in the team-compass project. Where would be a good place to add this info?

[jtpio]

Maybe we could add a new section to the readme here:

And do something similar in https://github.com/jupyter/notebook-team-compass.