Triage Edits

[wesleytodd]

With all the work being on I wanted to make sure these edits I had never pushed were available in case anyone could finish them up. I did some rebasing, but it probably needs a bit more work and for sure a commit clean up pass. I will prioritize the req/res stuff, but if I can I will also get to this over the next day or so. If anyone wants to take this over and see that it gets finished let me know and you can take over.

cc: @gireeshpunathil @dougwilson

[gireeshpunathil]

LGTM!

[dougwilson]

BTW, as I've been merging in the suggested changes on this PR, I thought does it even make sense to include in this repo the list of the triagers? We don't list all the collaborators in this repo, nor the TC members.

The triagers stretch much wider than this single repo, wider than even the org (seeing as there are three orgs). We currently manage the TC member list on expressjs.com ; should that be the same place for the triage list? My thought is that (1) it is more visible, if that is what people want from the list (we already know the list from, for example, the team membership) and (2) it's much more "meta" than this repo.

I was also thinking about it more just merging some of the other documents like the charter, etc. Ideally those apply to the entire organization at least. We don't have some kind of "meta" repo, so maybe the website repo is the stand in. Ideally this repo (and probably all of them?) would just link out to the actual location like on expressjs.com for those "meta documents" like the charter, etc.

Yes, I know that was a little off-topic and I'll raise some of the general points in another form as well so the discussion does not get lost here; it was more for context on my thoughts than to have the discussion here specifically--except for the triage membership list, that is :)

[jonchurch]

One place for contributors/TC/triagers/repo captains makes sense to me. An alternative could be keeping a list in this repo (as it's the heart of the project symbolically), and importing it to the express site.

[dougwilson]

An alternative could be keeping a list in this repo (as it's the heart of the project symbolically), and importing it to the express site.

Yep, definately can be done. The main issue I can foresee (as it's been happening right now) is that landing the triage request PRs would end up conflicting with the current (release process)[https://github.com/expressjs/express/blob/master/Release-Process.md]. Not just for the upcoming 4/5 change over (master would be on 4.x until 5.0 goes final; but traige PRs landed between that time would suddenly disappear from master until the next 4.x release...) but even for the minor release process (once we start the minor release branch, it's a juggle to land them in the right place).

Just seems silly to juggle them around to make sure they don't get lost since these PRs don't target a code release, which is what the processes were built around in this repo, haha.

[gireeshpunathil]

I strongly recommend to retain the triage team list in Contributing.md. That way, it gets more visibility, and the community benefits a lot from know people and their contact details.

I recognize the missing list here - committers and TC members (I myself is struggling to figure out who are express committers). But absence of that list should not be a reason for omitting another list IMO, but vice versa - presence of triagers list be a motivation to list TC and committers list?

[dougwilson]

I strongly recommend to retain the triage team list in Contributing.md. That way, it gets more visibility, and the community benefits a lot from know people and their contact details.

Alright, can do 👍 I will work to get all these landed, then. Once all these things get settled, I can actually then move the 4.18 branch to the top and begin to land those items. My thought is because having them in this repo is causing delays in getting release work cut due to the release process currently.

But absence of that list should not be a reason for omitting another list IMO, but vice versa - presence of triagers list be a motivation to list TC and committers list?

Yes, the main reason is that it conflicts with the release process.

[gireeshpunathil]

Yes, the main reason is that it conflicts with the release process.

can you elaborate on what is the conflict? Is it any different from any other functional PR would cause? Isn't it a transient stuff that occurs in a few days time?

[dougwilson]

can you elaborate on what is the conflict? Is it any different from any other functional PR would cause? Isn't it a transient stuff that occurs in a few days time?

So right now, the overall goal is to release 4.18, merge into 5.0 to release that out. Maybe a follow up 5.0 release for GA if that is not the GA release. The issue is that master branch remains the line 4 until 5.0 is GA. Thus if we end up cutting 4.18 before all these docs changes land onto master, they will never make it into the 5.0 branch until there is another 4.x release... assuming there is ever going to be one. And when 5.0 goes GA, and swaps out master to that, it would look like we lost those doc changes, as they would end up orphaned on the 4.x branch, not to make it back to master until there is may a 4.x release in the future.

Commits are only landed onto master if they are destined for the next patch release that that master branch represents. These doc-only changes end up in limbo, waiting until it is determined if the next version on that major line is going to be a patch version (so then they can land into master) or a minor version (in which they need to land into the minor branch).

[gireeshpunathil]

this is what I would suggest (based on the higher objective of getting these releases out ASAP). If there is a better alternative, others - feel free to suggest.

• release 4.18
• release 5.0.0 GA
• re-pr this doc
• until then keep this in triage branch

[dougwilson]

Effectively this leaves us in a few choices right now if we want to keep this list in this repo: (1) continue to work away on getting this and all the corresponding PRs landed onto master and then get the 4.18 rolling so we are sure all these changes end up in the new master branch or (2) we can continue to delay landing all of this until 5.0 becomes master and then land at that time so this is all incased on to master (3) land this all on the 5.0 branch now and then we need to explain folks need to open their triage role requests against that branch, but then they still won't show on master until 5.0 is GA or even like (4) just keep everything stowed away on a triage branch and then eventually rebase it all and bring it up to date on to master once 5.0 becomes GA, but it would still end up remaining hidden away from master.

[dougwilson]

Yea. The main issue with the triage branch choice is that the stop-gap there is likely one time; once we begin again on 6.0, this will come up again unless we think we won't still be adding triagers.

[gireeshpunathil]

I am in favor of option 2 in your proposal, living with the mentioned side effects.

[dougwilson]

Cool. I think what we need to land somewhere, at least, is what the current rules even are. Ideally rules that are in a pull request are still a proposal, though we have been living these rules -- and there are at least two copies of it currently in two different branches 😄 . If we are going to go forward with not landing this on master, then I think we need to get at least somewhere to be the source of truth for who are the members and what a traiger actually is (and how to become one). There have been a couple PR requests opened recently (ex #4239 #4224) that are not following the PR format outlined in this document, and it's hard to tell them it's wrong when it's not clear where to actually find them, haha.

[wesleytodd]

I think the end goal should be having all this information in one place and having a link to it across all the projects. The only reasonable way to do this IMO is to automate the list of triagers such that the list is automatically udpated from the list we maintain. I started this work in https://github.com/pkgjs/membership-updater, but have not had a chance to finish it. The idea is we have a list of rules about how folks get added to the triage team, and the automation just updates the right places. Since it is much more clear and easy to just have this in one place and link to it, I think the website is the most logical place to put it.

I also think the same logic applies to ALL the other shared community docs. The thing is, GitHub has some help there for organizations, but since we span multiple orgs we cannot just use that. IMO, because of this it makes sense to move all of it to the website, then make the Orgs have a .github repo which just links out to the website.

Once we have that, I think it is just a matter of enabling that action on the website repo. That way we get no long term maintenance burden, and when the 6.0 branch is cut it needs no updating or back porting, it is just a link out.

I know I have been a bit repetitive here, but with a small group and these administrative tasks taking time, the only long term way to manage them is automation. So that is why I have been focusing on that instead of the day-to-day issues lately. I think you all have that well in hand! That said, I have not delivered on all of it, so if there is anything which is particularly pressing let me know so I can focus on that, maybe this is one. Or if anyone wants to help out on the automation front, that as well!!

[jonchurch]

@wesleytodd @dougwilson Where do you think a good place to track administrative projects would be? I'm aware now of pkgjs/statusboard as well as pkgjs/membership-updater, and we've talked some future automation for expressjs.com here.

Maybe a milestone? Or a project board? Idk...

My goal here is to try and leverage the talented devs we have working on the project who might want to sink their teeth into helping write some fresh code. I'm interested in these projects, but don't have a single place to point folks to and say "these initiatives need help".

[wesleytodd]

I know this might be a meta answer, but I think the goal is the statusboard would be the place (to see updates on the statusboard work, see the statusboard 😂). Since it is hard to aggregate in an automated way across many orgs, the whole point of the status board was to pull the work into a single visible place.

That said, I think creating a project or some other issue/page to keep folks up-to-date is fine, and probably would live in the discussions repo.

[dougwilson]

Thanks @wesleytodd ! Yea, that is along the lines of my thoughts as well. We have in this repo docs that only apply to this repo and some that apply to the wider "Express.js project" (the three orgs), and it is hard to tell which is which, which I think is an additional problem. Along the idea of automation, as we continue to add people / projects, being add to manage this without it getting mixed into code processes (like in this repo) is very beneficial. And of course the fact that we need to be linking around between all the repos to the common documents (like CoC, as an example).

Besides the issue of which docs apply to the specific repo/the project as a whole, I think where I started to realize we are going down an unsustainable path is when we added the list of triagers to the doc, and the process to add was to make a PR to add your name (no issue with a process like that), but then seeing them pile up due to the coordination of it being made against a code repo, I think is what made me rethink this process.

I would say that I think from this discussion, there is a simple middle ground we can do and would also open up some parallel work streams:

We are already living this triage process, so I think we need to be transparent and have it documented, if possible, which we already have written up. We can merge the non-changing parts into the express code repo to live along side the other docs, so it is visible on master with them. Under expected circumstances, what merges into master in the coming days (perhaps all tonight if there is agreement) will be the last stuff into master for the period in which we release 5.0 as GA (in which it will become the new master).

In parallel, we can work to get the docs up on the website. We already have some of them mirrored on the site crushed onto a single page, so likely want to have a page per doc or something to make it more specific to link to and read (can add left nav bar like middleware & APi docs). Perhaps the website repo (or .github or governance or similar) will be made their actual home ("source of truth").

The process for listing folks can be worked out (I think having a public list of folks is good 100%), and perhaps could be neat with like the GitHub photos in circles, etc. to really emphasize the folks hard at work on the project. This can take the form of the membership sync style or start out with manual merging -- either one would work just fine in a repo without a code release process to work-around, I think.

[gireeshpunathil]

no concerns from anyone in today's TC on handling in whatever way that accelerates the release process. every one feels the project is important, so the list can wait if need be (or even they can re-pr if need be.)

• so pls exclude this item from the release process

[dougwilson]

so pls exclude this item from the release process

🤔 so the proposal was not to exclude it from the release process... what was the thoughts on the proposal above? If the idea is to do a different proposal from the above, can you list the reasons discussed for why and what the specific new proposal would be?

[gireeshpunathil]

there wasn't any discussions on multiple proposals and pros and cons of each. The only conviction we had was that this item should NOT come in between the (5.0) release.

The only reason we quoted is: project (and the release) is important over and above anything.

I don't think anyone read your proposal that was posted 5 minutes prior to the meeting, I may be wrong. I did not.

[dougwilson]

Ah, gotcha. So I think we should go with what I'm proposing unless there are any specific objections. If we want to wait some more for folks to read through it, I can definately do so 👍 . We need to work towards documenting things where possible, especially around governance. We need to have the triage governance documented somewhere as we have already started to perform it, which is where my proposal come from: a compromise between both of the concerns. I know when we don't have things documented and yet there are things being done, folks may get frustrated with the lack or un-discoverability of the documentation.

I can't start the 4.18 process until we make a decision around this, which is why it was the top of the TC meeting and I made for sure to write down what I would have said in the meeting in words here so everyone could read it and discuss in my absence. If that wasn't clear, I will do better in the future to raise that issue better. But it doesn't change that I cannot start 4.18 until we get this figured out... So I think we need to just keep moving forward, perhaps in text-only format or should we wait for the next TC meeting?

[gireeshpunathil]

I can't start the 4.18 process until we make a decision around this

Please don't let doc reasons to be release blockers. the missing doc can be re-pr'd, if need be.

Your proposal (land static part of the triage section) still has the risk of delaying release. I don't recommend that. Most straightforward and popular thing to do is to move past this and release.

[dougwilson]

How does the proposal risk delay of the release?

[gireeshpunathil]

How does the proposal risk delay of the release?

that needs a change to the doc, and needs to undergo a full PR life cycle.

[dougwilson]

OK, but so does the other 4.18 changes... Would this PR lifecycle take longer than the other 4.18 PRs? For example, I need to update the router bug fix PR, which would require the "full PR lifecycle" and after that, then of course comes the 4.18 PR, which would... also require the full PR lifecycle. Can these not run in parallel? I'm not clear on the specific risk here.

[gireeshpunathil]

Can these not run in parallel?

I have several examples of resource constraints in this project, especially on people with commit rights. You are super active, but many times we discussed your constraints too. So I am trying to be super-pragmatic here - weeding out ripples from super-priority items

[gireeshpunathil]

The statement of that is quite hurtful with all the time I put in to do those exact task and I am very much not inconvenienced to do them.

EDIT:
@dougwilson - I am not a native speaker, no so apologies if it cause any hurt to you.

My bottom line is that we don't have enough people to run the project in many critical areas (release is one of those, as you will agree). So let us don't let this task come in way of the release!

[dougwilson]

Right, but I'm trying to say that this isn't getting in the way of the release--the reason I am making my proposal is precisely to not get in the way of the release and to move it forward. So if we want to move forward, I want to get this done tonight, but I don't want to unilaterally just do it. So wanted to make sure folks were on board first... So the risk of delaying the release is by opposing my proposal, in fact...

[gireeshpunathil]

So the risk of delaying the release is by opposing my proposal, in fact...

sorry, I don't agree on that. I re-iterate my opinion: leave this aside and go ahead with release.

[dougwilson]

Ok, so I disagree on that... but that is OK, as the folks who need to come to a consensus are the repo committers or escalate to the TC members. I was hoping to discuss with the TC members at tonight's meeting, but none of the members were present. I'm going to go ahead with my proposal unless there is an objection by one of those groups.

[gireeshpunathil]

@expressjs/express-tc - can you pls chime in to resolve a difference in opinion here?

Problem: this PR can potentially conflict with the release process (If not landed in time, can leave the doc in an in-coherent state in different branches)

@dougwilson suggested to amend the PR to retain non-dynamic part of the PR.

I disagree on that, and propose to leave the PR and go ahead with release - affected parties are triagers. In today's TC meeting, they were more than happy to delay this till post release.

[gireeshpunathil]

per above conversation, dismissing stale review and requesting changes to the PR in its current form

[dougwilson]

I rebased this branch onto master and edited the membership request to be open an issue vs a pull request for the interim method of on boarding new members.

[dougwilson]

Hey @wesleytodd if you have some time, please take a look at the changes here. It's your changes, with a few fixes and just made to be static for the interim (I left my changes as individual commits to see what I changed specifically).

[dougwilson]

Ok, I think hopefully enough time has passed to enable a review. I'm going to squash + merge tonight ideally unless an objection appears.