-
Notifications
You must be signed in to change notification settings - Fork 136
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
Give Triagers access to the Node.js feature requests project #861
Comments
SGTM. I created that project and I don't think anyone's been maintaining it recently. |
If we have access, I'd gladly reorganize it (nodejs/node#52485). I really like it's concept, but it just needs a bit of oversight. |
+1 |
Great! I'll close this issue once we get access (or a different conclusion is reached) Thanks for your help! |
I'm glad we are a fan of this idea, I'm exciting to help out :-) |
Do you think it'll also be a good idea to create a Node.js bug reports project? I'm happy to manage it if needed |
What would you do with it? |
I meant just for tracking issues so that they are known |
/cc @nodejs/tsc |
It's been about a month without objections from the TSC, are we okay to give triagers access to the Node.js Feature Requests project? (For Bug Tracking, I've opened #874) |
I would have hoped to get a bit more interactions from TSC members, but yeah I suppose this counts as consensus. |
I'm just concerned with your plan. Could you elaborate more on what you want to do with the feature requests board? You explained very little about what you're actually going to do. Without a concrete plan, I'm -1, although I'm not TSC. |
I'm pretty sure nobody uses that board at the moment. I created it and attempted to maintain it a few years ago, but AFAIK it never gained interest from other collaborators. |
I see! Thx for clarifying. If there's no risk, then it's all good. Still, a concrete plan would always be preferable. I also wonder if we want to showcase the board somewhere? |
Agreed. |
Sorry, I intend to move the misplaced issues into the correct columns, as many are in the wrong places. (For example, closed issues are in waiting triage). |
@targos What was the goal of having the board in the first place? |
I don't remember exactly. The main goal was to use custom fields like the existing "status" classify issues and more easily filter them. |
My plan for this project is, if I am given access, remove the hundreds of items that are in the wrong place, making it easier for future users to find new tasks to work on, and triagers to find new issues to triage. |
Hey, still no objections, just curious whether this is still on the table. |
I invited the triage team with the Write role. |
Thanks! Would it be okay if I modified the project settings to remove items closed as stale or not planned, as projects have a maximum item count, and we have a decent amount of stale/not planned issues in the project. |
I don't think anyone is actually using that project, so as long as all effects are strictly contained to that project and don't affect labels on issues or so, nobody will have an issue with that. If anyone else ever actually starts using that project, we might have to come up with some rules around it, but it doesn't seem like there's interest in using the project so far. |
(CC @nodejs/issue-triage)
As a (relatively new) member of the Issue Triage team, I think it'd be reasonably helpful if we had the permissions to move issues around in the Node.js feature requests project. This way, we can mark issues as triaged/stale/fixed rather than waiting for the bot to mark them stale or an admin to change their status.
The text was updated successfully, but these errors were encountered: