In the past we've had an effort to find patches which can be handled by someone who is new to the patch process and doesn't understand coding well but wants to get some good experience. The system was to create a "patchnewbie" user and then assign them the issues. This seems like a good system since t makes patches easy to find, but it has the drawback of being time consuming.

I propose that we start adding some new issue statuses for things which are currently contained inside of "code needs work" but which can be done by anyone. One good example of this is for situations where the code needs to be re-rolled due to other nearby changes which cause the patch to no longer apply. This has the benefit of being easy for the reviewer to use and still easy to filter and find.

Thoughts?

Comments

dww’s picture

dww
we/he/they
commented

I'm not opposed, although I'm not sure "roll" is a universally understood verb for what you're talking about, and I'm not 100% clear on the guidelines that distinguish "needs re-roll" from "needs work" -- seems like a somewhat fuzzy distinction. Another thought is that it makes it harder for the automated testing bot to set issue status correctly when a patch no longer applies. Do we just always assume it's for "needs re-roll" in that case, and let humans filter out from there to "needs work"?

+0 ;)

mikey_p’s picture

mikey_p commented

Well its up to the testing bot to determine what the best status for the issue should be. Eventually one could see statuses for "patch(does not apply)" or "patch(tests do not pass)" etc, etc. One could make arguments that both of those are covered by "patch(code needs work)" and a sufficient description (which the testing bot could supply as well).

So the only reason to add statuses is if we need a way to sort upon those. So if someone can make a good case for needing to filter/sort by these statuses, then we should go for it.

Personally, I could see a use for it, but if we do go for that we should probably evaluate all the possible variations of "patch($extended_description_here)" before making changes.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

I'd far prefer to get http://drupal.org/project/comment_alter_taxonomy finished and on d.o. In fact, the fact that we don't have that is directly holding back a bunch of efforts I'd love to do as part of core maintainership. :(

This would allow us to tag issues like: postgresql, needs tests

Or: patch newbie, usability, needs tests, needs re-roll

DROP then becomes "Subscribe to the list of issues tagged as 'patch newbie'." Usability team can have their dedicated feed of usability issues. Same with the QA team, people who have postgresql, etc.

We currently try and hack this with the "Component" field, which is single-select only. Something can't be both "usability" and "patch newbie."

There are 5200+ active issues in the Drupal queue. The only way I see us taking that number down by a thousand or two is in providing tools for teams to find the issues that are geared towards them. I think adding another status isn't addressing the root problem of needing more rich metadata to describe this stuff.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Active » Closed (duplicate)

Thanks for the feedback, webchick. That sounds like a much better approach to me. I'll try to see what I can do to bring comment_alter_taxonomy into use.