express triage

[gireeshpunathil]

team -

I plan to spend some time helping with express triage, along with my colleague, @HarshithaKP

I had a meeting with @wesleytodd in August, and here is what that roughly came out:

We define a triage process and document it. The triage process is as follows:

1. tag all the open issues as: needs triage, bug or enhancement, based on the qualifying criteria that we apply after the due analysis on the issue
2. Document the process under https://github.com/expressjs/express/blob/master/Contributing.md for wider awareness so that no one (in the package maintenance team) is caught by surprise.

Please let me know what do you think!

• the scope for this initiative is all the repos under express umbrella
• we also entreat more people to join the triage team to reduce the backlog and improve our responsiveness to end-user issues
• we have started looking at multer as a starting point (based on backlog count), and touched some issues. Would be good if some of the owners or maintainers to have a look at those and share their candid opinions - we are not SMEs and not fully skilled in the technology (but definitely striving to ramp up!) so this feedback is important to make course corrections as we go!

Thanks in advance!

[wesleytodd]

Sorry I have been very busy since then, but I want this to move forward. I was hoping some of the other team members would have shared their opinions. If this does not get any objections soon I will start by adding you (@gireeshpunathil) to the triage role on this org. This should at least get "triagers" to be able to tag and close issues.

See here for more info on the new roles: https://help.github.com/en/articles/repository-permission-levels-for-an-organization

[dougwilson]

I'm so glad that github has improved the roles for members. I am onboard. There is a PR in express with the draft of the triage stuff, which I presume is related to this and I'll merge that into master shortly.

[helio-frota]

hi,
I'm interested in contribute with this effort by following the guidelines presented on the first comment, as well looking into multer as start point.

So, not a full time thing and not fully skilled in the technology, but yeah striving to ramp up.

[LinusU]

@helio-frota I would love to get some help with triaging in Multer. There are sooo many issues that are simply people asking how to do specific tings not really related to Multer, or that pastes some code and asks me to debug it.

I had a long vacation and my inbox still haven't recovered so I haven't been able to get to all projects, still have ~400 notifications left to go thru 😅

[helio-frota]

@LinusU yup, not a problem. 👍

But like @wesleytodd wrote on comment above:

This should at least get "triagers" to be able to tag and close issues.

After an overall look on issues and PRs, that is definitely one action to be done because we need to "cleanup the house" first to have a better focal point.

@wesleytodd When you have a time, can you please add me as "triagers" ?

@gireeshpunathil What do you think the triagers "/cc @" each other for each issue and PR so we can increase the % of response with a LGTM or a different point of view. Please let'me know.

@gireeshpunathil Here an example: expressjs/multer#798 (comment)
I exposed my opinion, and if you add a LGTM we close the PR.
The same applies for the others "triagers"

Please let me know if that approach makes sense

[gireeshpunathil]

@helio-frota - thanks.

• if triagers constitute a team together, @ mentioning is a good idea. Until such times, plain cc individuals makes sense.
• however, for closing non-trivial issues (where the OP have some convictions about the their point of view, there are differing views between involved parties etc.) I suggest we bring in the lead maintainer into the view to take a call?
• for trivial issues - yes, a mutual consensus or even direct closure (in case of inactive issues) make more sense
• I would prioritize issues over PRs.
• In my first scan of multer, I remember finding a good number of PR candidates emanating from issues I expect the similar pattern from other projects as well. When we interlock, we can discuss what, and how to treat insights coming out of triage work, for the long term benefit of the subject project.

[helio-frota]

I agree and going to get aligned with these points.

[wesleytodd]

👍 to everything @gireeshpunathil said, especially having non-trivial issues spot checked by one of the primary maintainers of the repo.

Also, to test it out @gireeshpunathil I gave you the triage role in this repo, can you make sure that you see all the appropriate buttons (tag, close, etc)?

@wesleytodd When you have a time, can you please add me as "triagers" ?

I need @dougwilson to add me (and probably the whole group of active TC members) as admin on the other orgs.

Also, for everyone here, can you start by reading and collaborating on the document started by @gireeshpunathil here: expressjs/express#4055

[gireeshpunathil]

thanks @wesleytodd - as you can see, I now have the triage role.

[wesleytodd]

@gireeshpunathil will post some more info, but to follow up after our sync:

• Added Triage team to all three orgs
• Added all of the repos to the team with the triage role
• Added @gireeshpunathil to the team as the first member

Once the process for adding to members is established it should be just a matter of adding them to three teams (one in each org), which can be done by anyone with the Owner role on that org.

[gireeshpunathil]

Apologies for the goofup, I said Dec 3 PST | Dec 4 IST for meeting with Doug and Wes, but actually sent a calendar for Dec 2 PST | Dec 3 IST! So the meeting actually happened. Here is the minutes of today's discussion:

• maintainer's feedback on the work some of us have been doing on some repos (e.g:- multer, session, body parser)
  • generally nice, please continue to do the good work. no concerns on the type and quality of contributions
• documenting the approach and best practices will be good for new comers who want to start triage work
  • Gireesh to push a commit to that effect into docs: add a triage section express#4055
• need a process for granting triage role to new comers
  • introduce a list of existing triagers.
  • new comers raise PR into that, adding themselves
  • project maintainers review, and act accordingly
  • the orgs subjected for triage are: jshttp, pillarjs and expressjs
  • triage team membership can be any of, few of, or all of those orgs
  • Gireesh is already added to the triagers; he is going to PR a list which others can add themselves into
• have a public repo, mainly for discussions on triage work - feedbacks, suggestions, general comments etc.
  • Wes will plan to create one

General consensus in the meeting was that the second meeting isn't necessary for now (just to convey this message etc.), instead we can have a discussion on the items in this thread and arrive at a consensus; and going forward (probably new year) have a single meeting to discuss traige themes.

So please share views / concerns, or if you are fine with this approach, pelase 👍 here

[jonchurch]

Hey there, I got introduced to this effort at the Montreal OpenJS Collab Summit by @wesleytodd and @gireeshpunathil.

I'm happy to help w/ triage, and have PR'd a request in expressjs/express#4132

I know things slow down as the year comes to a close, but I wanted to touch base and introduce myself 👋

I'd love to help coordinate any triage efforts and volunteer myself to help onboard other triagers once this whole thing gets set up.

[gireeshpunathil]

@jonchurch - thanks! in the new year, either we will have a recurring meeting to co-ordinate triage work, or the express TC meeting will extend to cover this topic too. So, let us all have a conversation in early January!

[jonchurch]

I went on a triage spree today, did most of my work in multer.

I answered some questions where I could, tagged issues where I could, and closed some that seemed resolved.

Any feedback @LinusU? Here are issues I commented on (don't think there's a way to search for issues that I tagged but didn't comment on).

There are some issues that seem dead and was curious what you thought about closing them?

expressjs/multer#711 for example, has been waiting for info for almost a year now. I would suggest closing it but didn't want to go too crazy on closing things (I am stopping here for the night, actually).

Can I assume I should close issues that have been resolved? Meaning an answer has been posted, or OP has confirmed that their issue was resolved either due to a comment or their own efforts.

[LinusU]

@jonchurch thank you so much for all you help, this is amazing!

There are some issues that seem dead and was curious what you thought about closing them?

Close at will! 🍻

expressjs/multer#711

I think that is a very good candidate for closing. You can also add a comment to say that we are happy to reopen the issue if the more information is provided, that's what I usually do.

Can I assume I should close issues that have been resolved?

Yes, that's great 👍

Again, huge thanks to you and everyone else here that is helping out, it's really appreciated ❤️

[wesleytodd]

Yeah, @jonchurch great work!

Can I assume I should close issues that have been resolved?

I think the ones you closed in other repos seem reasonable. I try to be careful and usually request that the OP close them if they feel it has been resolved, but I don't think that is required (especially for really old ones).

I have been a bit busy so have not finished my refactors on expressjs/express#4055, but I have progress on my computer, so maybe this weekend.

Keep up the good work team!

[dougwilson]

On the note of triagers @wesleytodd there are three that have still not even accepted their invite to the express orf team, so they cannot even triage still. Do you know if they are maybe just confused and waiting for some kind of onboarding process before they accept?

[wesleytodd]

@Sushmeet @AuggieH @mlrawlings

Can y'all let us know. If you are unable to or don't want to that is fine I can just remove the invite :)

[helio-frota]

@wesleytodd @dougwilson Hey, thanks for starting this discussion/subject.

In my case want to let you know that currently I have limited scope on triage but not zero. I'm on jshttp org, mainly reading and studying the source code 👍

I'm doing that as part of Red Hat, but also organizing my free time to improve my participation

[AuggieH]

@wesleytodd @dougwilson I never saw the invite. I'll take a look around for it.

[AuggieH]

I found the invite and accepted it. Could you remind me where the triage board is?

[jonchurch]

@AuggieH The statusboard is https://expressjs.github.io/statusboard/

But I don't believe it's up to date atm

What I've done is used https://github.com/RichardLitt/watch-gh-repos to subscribe to notifications for all the orgs expressjs, pillarjs, jshttp and have been watching notifications come in.

Also, multer was suggested as a good place to start clearing the backlog, which I have been working on.

As we're starting to get more folks on board, figuring out where to focus people and how to best utilize their time will be really important imo.

I started by combing through multer for old issues, closing things that are obviously resolved, labeling as many things as I could (with a special attention to sniffing out bugs and labeling them accordingly). It took a while to load the source code into my brain, discover which issues have been brought up before, learn what constitutes a bug, discover the work happening on the next major release and what changes it introduces, and generally get comfortable in the project. YMMV, but I had a number of mistakes where I labeled a bug, didn't fully understand an issue, or otherwise just had to go back and revisit things I had already touched but understood better after getting more context.

I should likely start a new issue or a doc or something to talk about this process specifically (re: onboarding and Q/A for triagers), I think doing so here would get off topic pretty quickly. Does anyone have an opinion about that? A working issue to help answer the very important question "okay I'm in, what should I do now and where should I start?" as efforts evolve and the need for attention shifts between orgs/projects.

I know there is a Triage document being worked on expressjs/express#4055 but I also think it would be a good idea to have a place where discussions w/ triagers and about the process itself will be on topic.

Any thoughts?

[Sushmeet]

@wesleytodd
Apologies seeing this now. I have accepted the invites to the three orgs. I am going over this and trying to figure out next steps

[mlrawlings]

@wesleytodd Never saw an invite, nor got an email best I can tell, but going to https://github.com/orgs/expressjs/invitation directly pulled it up, so I've now joined.

[wesleytodd]

But I don't believe it's up to date atm

It is not, I had to turn off the indexing because it was timing out the GH action. I will take a look at manually re-running it this week and see if it still times out. I brought this up int he last package maintenance WG call, but I will mention it here as well, if anyone is interested in fixing the @pkgjs/statusboard so that it does not re-index all projects at once that would be awesome. If you are interested in doing this work let me know and we can discuss the ways to do it.

[ryhinchey]

👋 My colleague told me about this effort and I recently listened to Wesley's talk at Node Interactive. I'd love to help as a triager.

I've opened a request here - expressjs/express#4185

After reading through this issue, I've started familiarizing myself with the different orgs and looking through open issues in multer. I'd also love to help organize and onboard triagers in the future.