Add carpasse as repo captain for response-time

[UlisesGascon]

I wanted to nominate @carpasse as repo captain for response-time.

He is interested in maintaining the package and has done significant work across the organization, including migrating to GitHub Actions and adopting the OSSF scorecard, among other things.

[wesleytodd]

Awesome! Yes @carpasse you have been great work helping across the orgs, thanks for that! I am in support of this, but I want to point out a few things (not at all personal to you Carlos).

1. This is the first person being given repo captain who is not a TC member
2. Carlos is not yet a "committer" on response-time
3. Carlos has landed one commit on response-time

That said, those of us who we brought on to the TC have not been active contributors on many of these individual projects we are taking stewardship of. So I don't think the details matter as much in the early phases. But the docs do state the following:

To become a captain for a project the candidate is expected to participate in that project for at least 6 months as a committer prior to the request. They should have helped with code contributions as well as triaging issues. They are also required to have 2FA enabled on both their GitHub and npm accounts. Any TC member or existing captain on the repo can nominate another committer to the captain role

If we want to amend those rules, great, as the goal is to have a robust and large group of maintainers on all these repos. But I believe that it might be prudent for all of us to keep some of this structure around so that as the group grows we can point to our contributing docs and say truthfully that "these are the processes we follow". Additionally, the only thing gated on captain over committer is the publish bit. Since there is nothing to publish immediately, I don't think it is blocking any progress to go slow.

With that in mind, what do we think about starting with giving @carpasse the committer role first? Again, this is nothing against you Carlos, I am super grateful for your work and it is really helpful to getting things moving in a good direction again. That way you can land updates and changes as needed over the next few months, and then we can just check the box that we did what our charter/docs say we would do?

[wesleytodd]

Honestly, I say this for more than just this first case, but we should be comfortable giving folks committer on these repos. So this goes for @carpasse or anyone seeing this, if you start contributing and want to help with more than just a "drive by contribution" then please reach out to a TC member or the listed Repo Captain and let us know. The process of adding a committer is just:

All contributors who land a non-trivial contribution should be on-boarded in a timely manner, and added as a committer, and be given write access to the repository.

Committers are expected to follow this policy and continue to send pull requests, go through proper review, and have other committers merge their pull requests.

So honestly we should probably add @carpasse and a few others as committer on a bunch of repos. If this applies to you, please raise your hand.

[carpasse]

@wesleytodd, thanks for your comments. To be honest, I am not particularly interested in becoming a repo captain. I am happy to continue contributing as a committer. I understand there is a process, and I am more than happy to follow it. I got involved with Response Time because we use it at my workplace, and I had a conversation with
@UlisesGascon about the possibility of upgrading the package dependencies and addressing open PRs and issues.

[wesleytodd]

Cool, If that works for you I think it is best to follow the process. I would be happy to see you also take it more fully over if that is something you would be interested in in the future, but just want to make sure we don't take our own "rules" too loosely.

I will go ahead and create the proper settings right now then.

[wesleytodd]

Created the new team and setup the permissions to maintain which should mean you can manage all the issues/prs and settings. If you do get a release prepared that you need pushed out I guess the current approach would be to make a branch and request @expressjs/express-tc reviews it and we can do the publish. Ideally I would say that longer term the captain role would be great because it removes us as the bottleneck on the release, but again there is process in place for a reason around that.