Open Bug 1128878 Opened 10 years ago Updated 4 years ago

Automatically check the status of assigned mentored bugs, and unassign them after a period of inactivity

Categories

(Community Building :: Contribute, task)

Product:
Community Building
Component:
Contribute
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: jdm, Unassigned)

References

Details

(Whiteboard: [lang=py][lang=js])

Attachments

(1 file)

my list of bugs
16.23 KB, text/plain
Details
It's common to find mentored bugs that have been assigned to a contributor weeks or months ago, with no subsequent followup from the assignee. This is currently handled on an ad-hoc basis; I propose writing a tool that will perform the following steps: * find the set of mentored bugs with an assignee where the last modified date is >3 weeks * Set the assignee back to default (nobody@mozilla.org) * Request needinfo? from the previous assignee * Leave a comment like "I have reset the assignee as part of an automated cleanup since there has been no visible activity in this bug for some time. If this is incorrect, please leave a comment to let me know and I'll correct the error." I recommend writing it in Python or node.js, since we have useful libraries for interacting with those languages in the form of bz.js and bzrest (both on github).
Whiteboard: [lang=py][lang=js]
Further we maybe could discuss what to do with bugs that have comments in it like "Could you please assign this bug to me?" or "Can I work on this?" but nobody has ever assigned the bug to them? (this is due to not having editbug permission)
Until now, the recommended practice has been to avoid assigning bugs to newcomers until they submit a patch. I believe the goal of this was to avoid the stale bugs with assignees problem that we're trying to fix here, so if this tool is adopted we might be able to move to a model of eagerly assigning bugs to people who express interest.
We would like to work on this. Can you point us to the API's that you use to query the codebase and bugzilla?
Note, those libraries interface with the REST API described here: https://wiki.mozilla.org/Bugzilla:REST_API
I will also point out https://landfill.bugzilla.org/bugzilla-tip/ as a great place for testing.
Great, thanks for the links! Our team is actively working on this. One question: where will the script live, and how/when would it be called? We're less experienced with javascript, but this will be a good opportunity for us to learn.
Ideally the tool would be launched like `nodejs main.js` or `python main.py` - that is, from the terminal rather than a web browser or any other GUI.
Oh, and as for where it will live, I suggest creating a github repository for the time being.
We will, thank you for the direction.
Should this be filed against bugzilla?
I think it will be easier to demonstrate value through an external tool. It also requires less Perl.
We are working on a solution, currently hosted at https://github.com/aaroncarsonart/AbandonedMentoredBugTracker . We are currently trying to figure out how to use the bugzilla landfill and to test our code that modifies the bugs on that site. Any guidance would be appreciated.
If you use the endpoint of https://landfill.bugzilla.org/bugzilla-tip/rest/ you should be able to use everything listed at https://wiki.mozilla.org/Bugzilla:REST_API#Examples_of_native_REST_API_use .
Scratch that! You should use bugzilla-dev.allizom.org, which is the staging server so the data there doesn't matter. You can do whatever you want there.
Hi! Our current status with this project is that the open source class has finished. We learned a lot, but we feel some of the requirements are a little above us at our grasp of javascript and trying to figure out bz.js and the bugzilla REST API. So far our script queries bugs successfully, and we figured out how to pass it login credentials. We have read though lots of documentation and while it seems to explain everything well we're struggling with the lack of a succinct example. It seems like a lot to learn all at once, and we are having troubles specifically with commenting on a bug via the script (properly instantiating and sending a bug with the Javascript API). As our team has reached the end of our major time commitment, we feel it may be best if we hand this off/declare our intent to stop working on this. Maybe someone with a greater grasp of the tools at hand can implement this better. I am open to looking into new possibilities if I can get more guidance, but most likely I will run out of time to look into this when the next term starts. Thank you for your help and guidance, we learned a lot working on this nonetheless.
Thanks for pushing all of your work to the repository :)
Hi I would love to pick this up. How do you envision this tool working? Would the person who builds the tool host it or is there some Bugzilla server that could just run it through cron? Sorry if that seems like a silly question I don't have much experience with contributing to open source yet.
I envision someone running it locally, either manually or automatically, until we figure out that it's providing indispensable value and figure out what its future is :) You would be welcome to work on it!
Great, thanks!
Hi I've made some progress on the tool. Who can I talk to about getting edit bug privileges on the allizom server that you mentioned. The JSON returned by landfill instance is different enough than the JSON from this Bugzilla that I want to test on something close to a production environment.
Flags: needinfo?(josh)
I have just granted you those privileges.
Flags: needinfo?(josh)
I have a python script that should work https://github.com/noliverio/Inactive-mentored-bug-tracker. It would be great if someone could give me a code review for it and advise on the next steps. Thanks!
Great work, Nick! I'll file some issues in the github repository for things I've noticed. What kind of testing have you performed on it?
Depends on: 1151718
> self.search_params = """f1=days_elapsed&list_id=10008579&o1=equals& > query_format=advanced&bug_status=ASSIGNED&v1=%s""" % self.length_of_inactivity_period this isn't the correct query -- you need to check for when the assignee field has changed, not when the bug's status was changed to assigned. i don't think it's possible to create the required query with bugzilla's search, but it would be easy for us to add a bespoke webservice method to provide the list to you. filed as bug 1151718.
(In reply to Byron Jones ‹:glob› from comment #25) > > self.search_params = """f1=days_elapsed&list_id=10008579&o1=equals& > > query_format=advanced&bug_status=ASSIGNED&v1=%s""" % self.length_of_inactivity_period > > this isn't the correct query -- you need to check for when the assignee > field has changed, not when the bug's status was changed to assigned. > > i don't think it's possible to create the required query with bugzilla's > search, but it would be easy for us to add a bespoke webservice method to > provide the list to you. filed as bug 1151718. I have updated the script on Github. With the existing api I was able to search for all bugs that are not assigned to nobody@mozilla.com. I do not believe that the custom webservice is necessary.
I have made the recommended changes, and tested it with the tests included in the repo. I am wondering what the next step is. Thanks.
Flags: needinfo?(josh)
Ack, sorry for letting this sit here. I've been thinking about the best way to introduce this tool and minimize the risk of any previously-undetected bugs from wreaking havoc on the live database. I propose we add a dry-run mode that just prints out the bugs that would be modified and exits - this will allow us to verify the results before committing them. Does that sound good?
Flags: needinfo?(josh)
That sounds like a good course of action. I have updated the script to include a dry run mode that will print the bug's id, it's mentor, it's assignee, and the date it was last changed for each bug that it would otherwise modify.
Fantastic! I'll run it tomorrow and look through the output.
Flags: needinfo?(josh)
(In reply to Josh Matthews [:jdm] from comment #30) > Fantastic! I'll run it tomorrow and look through the output. Just a heads up, if you want to read through the output with the current state of the database dry run will print out more or less a short novella's worth of information.
Attached file my list of bugs —
as a point of comparison here's the list of stale bugs which i find by querying the database directly (there's 154).
The output from the tool looks good to me; I've asked on dev.planning (https://www.mozilla.org/en-US/about/forums/#dev-planning) for any objections to kicking this off.
Flags: needinfo?(josh)
Hi Josh, did this bug get resolved?
Flags: needinfo?(josh)
I never followed up on my request to start running the script; in theory it's all ready.
Mentor: josh
Flags: needinfo?(josh)
Is this something we can deploy on heroku?
Flags: needinfo?(josh)
I'll pick this up and see what I can do. Josh left clear directions in the description.
Assignee: nobody → ehumphries
Flags: needinfo?(josh)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: