Hi.
Our Bugzilla installation at https://bugs.wikimedia.org/ currently restricts the capabilities of new users as a knee-jerk response to prior Bugzilla-related vandalism. There are further details at https://bugzilla.wikimedia.org/40497.
Increasingly new users are making manual requests to be assigned to bugs, as they cannot edit others' bugs by default. This is problematic and disruptive to development efforts.
My suggestion is to re-add the "editbugs" user right to new users by default (revert the old settings adjustment). Otherwise, an acceptable workaround needs to be found.
MZMcBride
So that's why suddenly I started receiving these email requests :D
On Wed, Nov 6, 2013 at 2:24 PM, MZMcBride z@mzmcbride.com wrote:
Hi.
Our Bugzilla installation at https://bugs.wikimedia.org/ currently restricts the capabilities of new users as a knee-jerk response to prior Bugzilla-related vandalism. There are further details at https://bugzilla.wikimedia.org/40497.
Increasingly new users are making manual requests to be assigned to bugs, as they cannot edit others' bugs by default. This is problematic and disruptive to development efforts.
My suggestion is to re-add the "editbugs" user right to new users by default (revert the old settings adjustment). Otherwise, an acceptable workaround needs to be found.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 11/06/2013 07:24 AM, Petr Bena wrote:
So that's why suddenly I started receiving these email requests :D
No, you are getting suddenly these emails from a group of students at http://foss.amrita.ac.in because a mentor told them to do so. We have explained the right process to them (asking in the bug report itself instead of sending private emails).
This is what Andre and me found out after asking to some of these potential volunteers. They are getting the bugs assigned, as requested. Let's see how many have the skills and determination to resolve the bugs.
After reading all this thread, I would be cautious changing the current setup. New users can't assign bugs to them, but nothing is stopping them to comment their intentions on the report itself, and actually fix the bug. If a potential contributor doesn't understand this (yet), there is also a chance that s/he won't be ready (yet) to fix the bug either, because that will probably require understanding other, more complex steps.
This might be one of those barriers that happen to be useful to understand better the complexity of a first task. I'm not sure we would get a significant benefit by removing it, even if we wouldn't get any of the vandalism that caused the introduction of the barrier in the first place.
Quim Gil wrote:
On 11/06/2013 07:24 AM, Petr Bena wrote:
So that's why suddenly I started receiving these email requests :D
No, you are getting suddenly these emails from a group of students at http://foss.amrita.ac.in because a mentor told them to do so. We have explained the right process to them (asking in the bug report itself instead of sending private emails).
This makes no sense to me. The issue is the extra step altogether.
--- Mentor practice: private e-mail users to assign bug, bug gets assigned, bugspam about bug being assigned
Your proposed practice: asking to be assigned on bug, bugspam about bug being commented on, bug gets assigned, bugspam about bug being assigned
Previous practice (pre-vandalism lockdown NEVER FORGET): bug gets assigned, bugspam about bug being assigned ---
I prefer the previous practice. Your proposal effectively just moves the mail from my main inbox to the Bugzilla folder. I suppose it's a slight improvement, but it misses the point that the overall workflow is broken.
MZMcBride
On 11/06/2013 04:24 PM, MZMcBride wrote:
Quim Gil wrote:
On 11/06/2013 07:24 AM, Petr Bena wrote:
So that's why suddenly I started receiving these email requests :D
No, you are getting suddenly these emails from a group of students at http://foss.amrita.ac.in because a mentor told them to do so. We have explained the right process to them (asking in the bug report itself instead of sending private emails).
This makes no sense to me. The issue is the extra step altogether.
The issue is the extra step for newcomers vs the risk of many extra steps for a few etablished contributors if someone decides to abuse the feature, as it happened in the past. And my point is that I personally don't believe that such barrier is diminishing the volume of actual contributions we receive.
In order to get somewhere with this discussion, it would be useful to know the current practice of other free software projects, using Bugzilla or not. As a newcomer, can I assign bugs to myself in GNOME, KDE, Ubuntu, Debian... etc?
For what is worth the Bugzilla mainainers decided to set the extra step by default and they were puzzled when RobLa told them that we had removed it in our big project.
On 07/11/13 16:28, Quim Gil wrote:
The issue is the extra step for newcomers vs the risk of many extra steps for a few etablished contributors if someone decides to abuse the feature, as it happened in the past. And my point is that I personally don't believe that such barrier is diminishing the volume of actual contributions we receive.
In order to get somewhere with this discussion, it would be useful to know the current practice of other free software projects, using Bugzilla or not. As a newcomer, can I assign bugs to myself in GNOME, KDE, Ubuntu, Debian... etc?
Would that be useful, though? Generally what other free software projects do is what works for them, and it won't necessarily work for us. It is also most especially not necessarily good practice when it comes to actually attracting and keeping new folks, simply due to the nature of what free software often entails - somewhere along the line, there is usually a lack of resources, and it is newcomers who suffer the most.
As much as projects would like, and for that matter, need, new folks, they only have so much time to devote to it and especially when volunteers make up a bulk of the community people wind up spending most time on other things. Bugzilla lacks certain key features that would make it feasible to open up from the start, and my guess would be it has something to do with similar - it was simply not a priority, so it never happened.
For a rather extreme example, there was another project, some OS thing, that a friend of mine wanted to contribute to awhile back, but he found that they had disabled account creation entirely due to lack of resources to combat spam, requiring instead that you find them on IRC or some such and contact them that way for an account. In no way is this good practice, and has very much harmed them as well, and yet it was probably the best thing they could do with what they had.
Just please be careful when looking at what other people do, here. Why they did something can be far more important than what they actually did.
I'm a little puzzled here: this whole discussion is because new owners want to have the bug actually assigned to them, instead of just commenting, "I'm working on this" in the bug?
Let's look at the github model -- there's no assignment at all. I just file a bug, maybe make some comments on it to say I'm working on it, and some time later I submit a pull request referencing the bug and saying, "I fixed it". That seems to work fine for collaboration, and offers no roadblocks.
Maybe we should be turning off bugzilla features instead of trying to 'fix' them. The whole 'file a bug in bugzilla' process is already far too complicated with a dozen fields which are either irrelevant or just confusing to newcomers. Can we just hide all this cruft (including the 'assigned to' field) for most users? --scott
On Thu, Nov 7, 2013 at 11:51 AM, Isarra Yos zhorishna@gmail.com wrote:
On 07/11/13 16:28, Quim Gil wrote:
The issue is the extra step for newcomers vs the risk of many extra steps for a few etablished contributors if someone decides to abuse the feature, as it happened in the past. And my point is that I personally don't believe that such barrier is diminishing the volume of actual contributions we receive.
In order to get somewhere with this discussion, it would be useful to know the current practice of other free software projects, using Bugzilla or not. As a newcomer, can I assign bugs to myself in GNOME, KDE, Ubuntu, Debian... etc?
Would that be useful, though? Generally what other free software projects do is what works for them, and it won't necessarily work for us. It is also most especially not necessarily good practice when it comes to actually attracting and keeping new folks, simply due to the nature of what free software often entails - somewhere along the line, there is usually a lack of resources, and it is newcomers who suffer the most.
As much as projects would like, and for that matter, need, new folks, they only have so much time to devote to it and especially when volunteers make up a bulk of the community people wind up spending most time on other things. Bugzilla lacks certain key features that would make it feasible to open up from the start, and my guess would be it has something to do with similar - it was simply not a priority, so it never happened.
For a rather extreme example, there was another project, some OS thing, that a friend of mine wanted to contribute to awhile back, but he found that they had disabled account creation entirely due to lack of resources to combat spam, requiring instead that you find them on IRC or some such and contact them that way for an account. In no way is this good practice, and has very much harmed them as well, and yet it was probably the best thing they could do with what they had.
Just please be careful when looking at what other people do, here. Why they did something can be far more important than what they actually did.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Let's look at the github model -- there's no assignment at all. I just file a bug, maybe make some comments on it to say I'm working on it, and some time later I submit a pull request referencing the bug and saying, "I fixed it". That seems to work fine for collaboration, and offers no roadblocks.
GitHub issues are owned by whoever submitted them (and the project owner). You can't for example convert an issue to a pull request if you are a third-party.
But you can always reference an issue in a commit or a comment though.
//Saper
C. Scott Ananian wrote:
Maybe we should be turning off bugzilla features instead of trying to 'fix' them. The whole 'file a bug in bugzilla' process is already far too complicated with a dozen fields which are either irrelevant or just confusing to newcomers. Can we just hide all this cruft (including the 'assigned to' field) for most users?
I think we should certainly evaluate and re-evaluate the Bugzilla workflow. There are surely fields in the current form that could be killed or made smarter (e.g., only display if necessary). It'd be nice to have a bug to track doing this evaluation, though I think any audit will find that the 'assigned to' field in particular is too disruptive to remove.
The general point about trusting new users is what this thread is about. Isarra's post makes for good reading. :-)
Isarra Yos wrote:
For a rather extreme example, there was another project, some OS thing, that a friend of mine wanted to contribute to awhile back, but he found that they had disabled account creation entirely due to lack of resources to combat spam, requiring instead that you find them on IRC or some such and contact them that way for an account. In no way is this good practice, and has very much harmed them as well, and yet it was probably the best thing they could do with what they had.
We're doing really well on this front, I think. Users can create a Gerrit/Labs/Wikitech account easily and without manual intervention.
Jeremy Baron wrote:
On Nov 7, 2013 6:27 PM, "Andre Klapper" aklapper@wikimedia.org wrote:
For the records: Currently 14744 Wikimedia Bugzilla users have editbugs permissions (so this is something to do via an SQL command instead of me clicking myself to death in Bugzilla's web interface).
I also generally support this. But maybe we can limit to only users that have done at least one or two actions in the last X months. Or exclude people that haven't logged in for a year. 14.7k sounds like a lot.
Okay.
As to your other questions, I'm confident we'll be able to figure out the logistical details, if needed.
MZMcBride
On Thu, Nov 7, 2013 at 9:06 AM, C. Scott Ananian cananian@wikimedia.orgwrote:
I'm a little puzzled here: this whole discussion is because new owners want to have the bug actually assigned to them, instead of just commenting, "I'm working on this" in the bug?
Let's look at the github model -- there's no assignment at all. I just file a bug, maybe make some comments on it to say I'm working on it, and some time later I submit a pull request referencing the bug and saying, "I fixed it". That seems to work fine for collaboration, and offers no roadblocks.
Maybe we should be turning off bugzilla features instead of trying to 'fix' them. The whole 'file a bug in bugzilla' process is already far too complicated with a dozen fields which are either irrelevant or just confusing to newcomers. Can we just hide all this cruft (including the 'assigned to' field) for most users? --scott
I would be okay just turning off assignment.
In theory, a primary use case for assigning bugs is Product Manager A (say, me) sees a new bug, and assigns it to Engineer B (say, Ori). Other than self-assignment, this kind of workflow is the most common argument for needing assignment I think. Since generally, WMF engineering teams use a secondary task tracking tool (Trello, Mingle, etc.), turning off the feature would not hurt us. We can also, you know, talk to people if we want them to tackle a bug.
Since we have PATCH TO REVIEW and cross-linking from Gerrit to BZ, it becomes clear who is actually working on resolving an issue. This also focuses more on actually getting working software patches, instead of just fiddling with bugs. ;)
On Fri, Nov 8, 2013 at 2:09 PM, Steven Walling steven.walling@gmail.comwrote:
On Thu, Nov 7, 2013 at 9:06 AM, C. Scott Ananian <cananian@wikimedia.org
wrote:
I'm a little puzzled here: this whole discussion is because new owners
want
to have the bug actually assigned to them, instead of just commenting,
"I'm
working on this" in the bug?
Let's look at the github model -- there's no assignment at all. I just file a bug, maybe make some comments on it to say I'm working on it, and some time later I submit a pull request referencing the bug and saying,
"I
fixed it". That seems to work fine for collaboration, and offers no roadblocks.
Maybe we should be turning off bugzilla features instead of trying to
'fix'
them. The whole 'file a bug in bugzilla' process is already far too complicated with a dozen fields which are either irrelevant or just confusing to newcomers. Can we just hide all this cruft (including the 'assigned to' field) for most users? --scott
I would be okay just turning off assignment.
In theory, a primary use case for assigning bugs is Product Manager A (say, me) sees a new bug, and assigns it to Engineer B (say, Ori). Other than self-assignment, this kind of workflow is the most common argument for needing assignment I think. Since generally, WMF engineering teams use a secondary task tracking tool (Trello, Mingle, etc.), turning off the feature would not hurt us. We can also, you know, talk to people if we want them to tackle a bug.
Not all teams have drank the Mingle Kool-Aid yet ;-)
-Chad
On Fri, Nov 8, 2013 at 2:12 PM, Chad innocentkiller@gmail.com wrote:
Not all teams have drank the Mingle Kool-Aid yet ;-)
That includes mine. :) Chad: does Platform really depend on bug assignment? Maybe Dan Garry could chime in here as well.
On Fri, Nov 8, 2013 at 2:14 PM, Steven Walling steven.walling@gmail.comwrote:
On Fri, Nov 8, 2013 at 2:12 PM, Chad innocentkiller@gmail.com wrote:
Not all teams have drank the Mingle Kool-Aid yet ;-)
That includes mine. :) Chad: does Platform really depend on bug assignment? Maybe Dan Garry could chime in here as well.
People may use it. I don't. I basically ignore assignee/status/priority fields.
-Chad
On Fri, Nov 8, 2013 at 2:31 PM, Chad innocentkiller@gmail.com wrote:
On Fri, Nov 8, 2013 at 2:14 PM, Steven Walling steven.walling@gmail.comwrote:
On Fri, Nov 8, 2013 at 2:12 PM, Chad innocentkiller@gmail.com wrote:
Not all teams have drank the Mingle Kool-Aid yet ;-)
That includes mine. :) Chad: does Platform really depend on bug assignment? Maybe Dan Garry could chime in here as well.
People may use it. I don't. I basically ignore assignee/status/priority fields.
*assignee/severity/priority.
I totally do care about status :)
-Chad
On Fri, Nov 8, 2013 at 2:14 PM, Steven Walling steven.walling@gmail.com wrote:
On Fri, Nov 8, 2013 at 2:12 PM, Chad innocentkiller@gmail.com wrote:
Not all teams have drank the Mingle Kool-Aid yet ;-)
That includes mine. :) Chad: does Platform really depend on bug assignment?
Yes.
Rob
On 11/08/2013 11:09 PM, Steven Walling wrote:
I would be okay just turning off assignment.
I don't support turning off assignment. A large number of MediaWiki projects use only Bugzilla (which is also the only open source tracker the WMF uses). Even for stuff WMF engineers work on, there are plenty of bugs only in Bugzilla.
Assignment is useful to me for multiple reasons, but the most important are:
1. Marking things I'm definitely going to work on (while trying to avoid cookie-licking). Importantly, I can unmark myself as assigned, signally that it's "back in the pool". 2. (Less commonly) Assigning other people, most commonly on things I think they have the inclination and expertise to fix.
Matt Flaschen
On Sat, Nov 9, 2013 at 1:24 AM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
Assignment is useful to me for multiple reasons, but the most important are:
- Marking things I'm definitely going to work on (while trying to avoid
cookie-licking). Importantly, I can unmark myself as assigned, signally that it's "back in the pool".
More agressive use of tagging (or something like it) would help here. I also list using the 'my bugs' feature of bugzilla. But that doesn't actually necessarily need to be reflected as 'assignment'. If there were a way to let me add to a list of 'my bugs' without requiring assignment (or editbugs) that would be totally cool.
- (Less commonly) Assigning other people, most commonly on things I think
they have the inclination and expertise to fix.
FWIW, the github system seems to use @username tagging to do this. That is, if this bug is relevant to @joeluser, the owner of the project typically comments, "this looks like this is up your alley, @joeluser" which sends an email notification. @joeluser then decides whether to add this to their personal 'my bugs' list (which is only mental at this point, since github doesn't support bug lists). --scott
And to be clear, I'm not advocating turning off assignment entirely for all projects and everyone. What I am advocating is that we (begin the process of) 'turning off' a large number of unused bugzilla features for most users, to reduce confusion and help encourage understanding of the workflow.
That is, perhaps there's a preference to see 'advanced fields' which defaults to off for everyone (and 'on' for members of the Platform team?). New users won't see fields which (a) they can't change and (b) don't matter anyway. --scott
On Sat, Nov 9, 2013 at 9:40 AM, C. Scott Ananian cananian@wikimedia.orgwrote:
On Sat, Nov 9, 2013 at 1:24 AM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
Assignment is useful to me for multiple reasons, but the most important are:
- Marking things I'm definitely going to work on (while trying to avoid
cookie-licking). Importantly, I can unmark myself as assigned, signally that it's "back in the pool".
More agressive use of tagging (or something like it) would help here. I also list using the 'my bugs' feature of bugzilla. But that doesn't actually necessarily need to be reflected as 'assignment'. If there were a way to let me add to a list of 'my bugs' without requiring assignment (or editbugs) that would be totally cool.
- (Less commonly) Assigning other people, most commonly on things I
think they have the inclination and expertise to fix.
FWIW, the github system seems to use @username tagging to do this. That is, if this bug is relevant to @joeluser, the owner of the project typically comments, "this looks like this is up your alley, @joeluser" which sends an email notification. @joeluser then decides whether to add this to their personal 'my bugs' list (which is only mental at this point, since github doesn't support bug lists). --scott
C. Scott Ananian wrote:
And to be clear, I'm not advocating turning off assignment entirely for all projects and everyone. What I am advocating is that we (begin the process of) 'turning off' a large number of unused bugzilla features for most users, to reduce confusion and help encourage understanding of the workflow.
I'll just reiterate what I said previously: it would be wonderful to do a full evaluation/audit of the current Bugzilla inputs and figure out which we can eliminate or make smarter (e.g., only display under certain conditions). However my personal view (which seems to be lightly supported by anecdotal evidence from this mailing list) is that the 'assigned to' field in particular is too disruptive to remove.
Links you may be interested in:
* https://www.mediawiki.org/wiki/Requests_for_comment/Bugzilla_taxonomy * https://www.mediawiki.org/wiki/Requests_for_comment/Overthrow_Bugzilla
(Not that anybody is seriously suggesting replacing Bugzilla, but you may still find the discussion interesting.)
That is, perhaps there's a preference to see 'advanced fields' which defaults to off for everyone (and 'on' for members of the Platform team?). New users won't see fields which (a) they can't change and (b) don't matter anyway.
This already exists. :-) By default, users only see a basic input form. You have to click "show advanced fields" to show all of the fields. Similarly, you can hide the advanced fields, though users sometimes have difficulty finding the control (it's kind of hiding in plain sight).
MZMcBride
I don't think assignment is the main usecase for editbugs. Things like marking as duplicate are.
Requiring people to ask is a barrier (especially when it's essentially unknown who to ask). I wouldn't be surprised if we lose otherwise useful contributors because they are too shy to ask or just don't know they can.
-bawolff
Why not make assigning bugs work sort of like FlaggedRevs -- as a new user, you can make changes, but the changes won't take effect until they're reviewed and approved? After a bureaucrat sees that you're behaving responsibly, or after you've made a certain number of changes that have been approved, then your changes are automatically approved.
With that system, you don't have to make a request of any particular person; it's whoever is the first to see that there are changes that need to be reviewed.
On Sat, Nov 9, 2013 at 6:51 PM, Nathan Larson nathanlarson3141@gmail.com wrote:
Why not make assigning bugs work sort of like FlaggedRevs -- as a new user, you can make changes, but the changes won't take effect until they're reviewed and approved? After a bureaucrat sees that you're behaving responsibly, or after you've made a certain number of changes that have been approved, then your changes are automatically approved.
With that system, you don't have to make a request of any particular person; it's whoever is the first to see that there are changes that need to be reviewed.
errr, patches welcome, etc.
-Jeremy
On Sat, 2013-11-09 at 10:22 -0400, MZMcBride wrote:
I'll just reiterate what I said previously: it would be wonderful to do a full evaluation/audit of the current Bugzilla inputs and figure out which we can eliminate or make smarter (e.g., only display under certain conditions).
Just to explain the current situation:
*Custom* fields (in Wikimedia Bugzilla: "Web Browser" and "Mobile Platform") can be configured to be only shown under certain conditions (e.g. only for specific products/components), but Bugzilla still does not allow disabling some *default* fields that I consider useless in most cases for us ("Hardware" and "OS", upstream ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=763409 ).
While some pieces of the criticism on that page are entirely valid, all in all it feels rather non-constructive. Plus the topic "most acceptable issue tracking/version control/project management tool" is so complex and has enough stakeholders that it requires a well-structured process to neither discuss only the favorite bits and pieces of individuals, nor end up in the biggest bikeshed ever.
andre
On Sat, Nov 9, 2013 at 9:40 AM, C. Scott Ananian cananian@wikimedia.orgwrote:
On Sat, Nov 9, 2013 at 1:24 AM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
Assignment is useful to me for multiple reasons, but the most important are:
- Marking things I'm definitely going to work on (while trying to avoid
cookie-licking). Importantly, I can unmark myself as assigned, signally that it's "back in the pool".
More agressive use of tagging (or something like it) would help here. I also list using the 'my bugs' feature of bugzilla. But that doesn't actually
*like using
necessarily need to be reflected as 'assignment'. If there were a way to let me add to a list of 'my bugs' without requiring assignment (or editbugs) that would be totally cool.
Fixing 'my bugs' to not require assignment would also reduce the cookie-licking problem, so I think it would have beneficial social effects (beside reducing the barrier to entry for non-editbugs-having contributors). --scott
On Sat, 2013-11-09 at 09:40 -0500, C. Scott Ananian wrote:
More agressive use of tagging (or something like it) would help here.
Tagging: For the records, Bugzilla offers 1) static global keywords in the "Keywords" field (see the list of keywords at https://bugzilla.wikimedia.org/describekeywords.cgi ), 2) public entries in the "Status Whiteboard" field (e.g. I sometimes set "aklapper-moreinfo" there), and 3) non-public, personal tags; completely unusable in our version 4.2 also thanks to our custom CSS; but acceptable in version 4.4 (see https://bugzilla.wikimedia.org/show_bug.cgi?id=56183 ).
I also list using the 'my bugs' feature of bugzilla. But that doesn't actually necessarily need to be reflected as 'assignment'. If there were a way to let me add to a list of 'my bugs' without requiring assignment (or editbugs) that would be totally cool.
I don't know your specific usecase - maybe the shared saved search named ""My" CC'd Bugs" might work (or not) which you could enable on https://bugzilla.wikimedia.org/userprefs.cgi?tab=saved-searches (see http://blogs.gnome.org/aklapper/2013/07/12/bugzillatips-saved-searches/ for general info on saved searches and sharing them with other users).
andre
Andre Klapper aklapper@wikimedia.org wrote:
I don't know your specific usecase - maybe the shared saved search named ""My" CC'd Bugs" might work (or not) which you could enable on https://bugzilla.wikimedia.org/userprefs.cgi?tab=saved-searches (see http://blogs.gnome.org/aklapper/2013/07/12/bugzillatips-saved-searches/ for general info on saved searches and sharing them with other users).
I've been using "i-am-on-cc" (now shared) filter similar to this one to a great success to find stuff I am working on/interested in.
//Saper
Marcin Cieslak wrote:
Andre Klapper aklapper@wikimedia.org wrote:
I don't know your specific usecase - maybe the shared saved search named ""My" CC'd Bugs" might work (or not) which you could enable on https://bugzilla.wikimedia.org/userprefs.cgi?tab=saved-searches (see http://blogs.gnome.org/aklapper/2013/07/12/bugzillatips-saved-searches/ for general info on saved searches and sharing them with other users).
I've been using "i-am-on-cc" (now shared) filter similar to this one to a great success to find stuff I am working on/interested in.
While we're sharing Bugzilla experiences...
A few weeks ago I made a filter (saved search) called "BUGZ" that tracks bugs where I've commented, I'm on the CC list, I'm the reporter, or it's assigned to me, limiting to unresolved tickets (but including the new PATCH_TO_REVIEW status), sorted in reverse chronological order by date changed.
It seems to work pretty well, basically duplicating the bugspam feed I get. I'm not sure there's a way to generalize it in our version of Bugzilla (the search currently hardcodes my e-mail address, I think).
I have two small quibbles with it: if a bug has only its CC field changed, the date changed still gets bumped and it requires looking at the bug history to figure out what happened. And if a bug has recently been marked resolved, it gets bumped from the list. Other than that, it was worth the few minutes it took to finally set up a custom filter for myself. I removed the others from the sidebar to decrease interface noise.
MZMcBride
On Thu, 2013-11-07 at 12:06 -0500, C. Scott Ananian wrote:
I'm a little puzzled here: this whole discussion is because new owners want to have the bug actually assigned to them, instead of just commenting, "I'm working on this" in the bug?
Let's look at the github model -- there's no assignment at all. I just file a bug, maybe make some comments on it to say I'm working on it, and some time later I submit a pull request referencing the bug and saying, "I fixed it". That seems to work fine for collaboration, and offers no roadblocks.
Maybe we should be turning off bugzilla features instead of trying to 'fix' them. The whole 'file a bug in bugzilla' process is already far too complicated with a dozen fields which are either irrelevant or just confusing to newcomers. Can we just hide all this cruft (including the 'assigned to' field) for most users?
Everything below only refering to enter_bug.cgi, not show_bug.cgi:
After clicking "Hide Advanced fields" in the upper left corner on https://bugzilla.wikimedia.org/enter_bug.cgi , the "Assignee" field is not shown anymore on the "Report a bug" page.
By default, the advanced fields are hidden on enter_bug.cgi: http://bzr.mozilla.org/bugzilla/trunk/view/head:/template/en/default/bug/cre...
If we wanted, we could probably hide more fields (OS, Hardware, ...) by wrapping the corresponding <tr>s in <tbody class="expert_fields">.
andre
On Thu, 2013-11-07 at 08:28 -0800, Quim Gil wrote:
In order to get somewhere with this discussion, it would be useful to know the current practice of other free software projects, using Bugzilla or not. As a newcomer, can I assign bugs to myself in GNOME, KDE, Ubuntu, Debian... etc?
In case any projects which use Bugzilla allow this: I just learned it's a bad idea [1]. The assignee of a bug report who is not member of the "editbugs" group defacto has "editbugs" permissions for that specific bug report. So you could mass-assign bug reports to you in order to bypass your missing editbugs permissions.
andre
[1] https://groups.google.com/forum/#!topic/mozilla.support.bugzilla/6GCB7ufa7nc
On Fri, Nov 8, 2013 at 6:52 AM, Andre Klapper aklapper@wikimedia.orgwrote:
On Thu, 2013-11-07 at 08:28 -0800, Quim Gil wrote:
In order to get somewhere with this discussion, it would be useful to know the current practice of other free software projects, using Bugzilla or not. As a newcomer, can I assign bugs to myself in GNOME, KDE, Ubuntu, Debian... etc?
It has been a while, but to my recollection, the answer is "no".
Luis
Again, as far as I'm concerned, we're solving a non-problem. Yes, in theory it would be nice if everyone easily got all permissions to everything. But bugzilla is not set up with the antivandal features needed to make that work. Instead, we should aim to make it possible for newcomers to easily get the permissions *that they need*. I'm not convinced that the ability to assign bugs themselves is an ability *that is needed* by most committers. They only think they need it because (1) we make the field visible, along with a bunch of other unused and unnecessary stuff, and (2) we have bugzilla set up to automatically "assign" bugs to default owners, even if (as is usually the case) the default owners do not plan to work on those bugs.
If newly entered bugs were put in an unassigned state, and the assignment field was hidden for untrusted users when the bugs were unassigned, I think we wouldn't have a problem here. We'd just handle assignment manually using comments in the bug, just as we go with github, etc. If a user starts working on such a long list of bugs that they need bugzilla's (broken, sigh, but it's what we've got) bug list management functions, they can ask to be officially assigned to a bug and/or ask for 'editbugs' permission. This is a huge subset of committers, and so can be handled manually.
The principle is that *new contributors shouldn't face roadblocks*. No one has convinced me that the inability to assign bugs to themselves is actually a *roadblock* for new contributors. It's just a *perceived roadblock*, caused by bugzilla's broken design. --scott
On Fri, Nov 8, 2013 at 10:30 AM, Luis Villa lvilla@wikimedia.org wrote:
On Fri, Nov 8, 2013 at 6:52 AM, Andre Klapper <aklapper@wikimedia.org
wrote:
On Thu, 2013-11-07 at 08:28 -0800, Quim Gil wrote:
In order to get somewhere with this discussion, it would be useful to know the current practice of other free software projects, using Bugzilla or not. As a newcomer, can I assign bugs to myself in GNOME, KDE, Ubuntu, Debian... etc?
It has been a while, but to my recollection, the answer is "no".
Luis
-- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810
NOTICE: *This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity.* _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 6 November 2013 13:24, MZMcBride z@mzmcbride.com wrote:
Our Bugzilla installation at https://bugs.wikimedia.org/ currently restricts the capabilities of new users as a knee-jerk response to prior Bugzilla-related vandalism. There are further details at https://bugzilla.wikimedia.org/40497.
My suggestion is to re-add the "editbugs" user right to new users by
default (revert the old settings adjustment). Otherwise, an acceptable workaround needs to be found.
Given that the majority of the vandalism occurred in 2011, I think that sufficient time has passed for us to re-add the right to all new users, and if we have issues with vandalism in the future, then we can re-assess and see what other options we can consider (such as some implementation of "autoconfirmed" as suggested at < https://bugzilla.wikimedia.org/show_bug.cgi?id=40497#c12%3E).
On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride z@mzmcbride.com wrote:
Our Bugzilla installation at https://bugs.wikimedia.org/ currently restricts the capabilities of new users as a knee-jerk response to prior Bugzilla-related vandalism. There are further details at https://bugzilla.wikimedia.org/40497.
As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt with most of the aftermath of the attacks that we received that ultimately led to it being turned off. It was not a knee jerk response. We temporarily turned it off and turned it back on a few days later, only to have dozens (hundreds?) of bugs altered in a way that was not easily reversed.
In consulting with the Bugzilla developers (I believe I may have sent a public mail about this to their list), their answer was essentially that Bugzilla was never designed for giving editbugs to untrusted users, and that by doing so, we had what was coming to us.
We tried reversing it several times, and each time were rewarded with an arduous cleanup task. We gave up trying after months. So, calling it "kneejerk" is simply wrong. We had a determined vandal who may still be among us, and will likely exploit whatever loophole we open up.
Increasingly new users are making manual requests to be assigned to bugs,
as they cannot edit others' bugs by default. This is problematic and disruptive to development efforts.
My suggestion is to re-add the "editbugs" user right to new users by default (revert the old settings adjustment). Otherwise, an acceptable workaround needs to be found.
I don't think we can pretend that the vandalism issue is solved, because it isn't. Bugzilla doesn't have the vandalism fighting tools that MediaWiki does.
We can certainly do something different than what we're doing, though. It should be easy to get editbugs; just not so easy that a vandal can get it.
Anyone have any ideas how to mitigate the vandalism problem?
Rob
I don't want anything to stand in the way of good users
Perhaps something similar to autoconfirmed as Thehelpfulone suggested, i.e. X total edits across all Wikimedia projects (or on a single Wikimedia project), and account was created Y days ago. There are details to work through with that (e.g. how do we verify bugzilla user a@b.com owns the global account they say they do?), but I think it's a good approach.
Dan
On 6 November 2013 15:38, Rob Lanphier robla@wikimedia.org wrote:
On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride z@mzmcbride.com wrote:
Our Bugzilla installation at https://bugs.wikimedia.org/ currently restricts the capabilities of new users as a knee-jerk response to prior Bugzilla-related vandalism. There are further details at https://bugzilla.wikimedia.org/40497.
As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt with most of the aftermath of the attacks that we received that ultimately led to it being turned off. It was not a knee jerk response. We temporarily turned it off and turned it back on a few days later, only to have dozens (hundreds?) of bugs altered in a way that was not easily reversed.
In consulting with the Bugzilla developers (I believe I may have sent a public mail about this to their list), their answer was essentially that Bugzilla was never designed for giving editbugs to untrusted users, and that by doing so, we had what was coming to us.
We tried reversing it several times, and each time were rewarded with an arduous cleanup task. We gave up trying after months. So, calling it "kneejerk" is simply wrong. We had a determined vandal who may still be among us, and will likely exploit whatever loophole we open up.
Increasingly new users are making manual requests to be assigned to bugs,
as they cannot edit others' bugs by default. This is problematic and disruptive to development efforts.
My suggestion is to re-add the "editbugs" user right to new users by default (revert the old settings adjustment). Otherwise, an acceptable workaround needs to be found.
I don't think we can pretend that the vandalism issue is solved, because it isn't. Bugzilla doesn't have the vandalism fighting tools that MediaWiki does.
We can certainly do something different than what we're doing, though. It should be easy to get editbugs; just not so easy that a vandal can get it.
Anyone have any ideas how to mitigate the vandalism problem?
Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Pre-emptive send wins again. That was meant to be "I don't want anything to stand in the way of good users filing bug reports, but we need to be aware of the previous issues that led to the current situation."
Dan
On 6 November 2013 15:45, Dan Garry dgarry@wikimedia.org wrote:
I don't want anything to stand in the way of good users
Perhaps something similar to autoconfirmed as Thehelpfulone suggested, i.e. X total edits across all Wikimedia projects (or on a single Wikimedia project), and account was created Y days ago. There are details to work through with that (e.g. how do we verify bugzilla user a@b.com owns the global account they say they do?), but I think it's a good approach.
Dan
On 6 November 2013 15:38, Rob Lanphier robla@wikimedia.org wrote:
On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride z@mzmcbride.com wrote:
Our Bugzilla installation at https://bugs.wikimedia.org/ currently restricts the capabilities of new users as a knee-jerk response to prior Bugzilla-related vandalism. There are further details at https://bugzilla.wikimedia.org/40497.
As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt with most of the aftermath of the attacks that we received that ultimately led to it being turned off. It was not a knee jerk response. We temporarily turned it off and turned it back on a few days later, only to have dozens (hundreds?) of bugs altered in a way that was not easily reversed.
In consulting with the Bugzilla developers (I believe I may have sent a public mail about this to their list), their answer was essentially that Bugzilla was never designed for giving editbugs to untrusted users, and that by doing so, we had what was coming to us.
We tried reversing it several times, and each time were rewarded with an arduous cleanup task. We gave up trying after months. So, calling it "kneejerk" is simply wrong. We had a determined vandal who may still be among us, and will likely exploit whatever loophole we open up.
Increasingly new users are making manual requests to be assigned to bugs,
as they cannot edit others' bugs by default. This is problematic and disruptive to development efforts.
My suggestion is to re-add the "editbugs" user right to new users by default (revert the old settings adjustment). Otherwise, an acceptable workaround needs to be found.
I don't think we can pretend that the vandalism issue is solved, because it isn't. Bugzilla doesn't have the vandalism fighting tools that MediaWiki does.
We can certainly do something different than what we're doing, though. It should be easy to get editbugs; just not so easy that a vandal can get it.
Anyone have any ideas how to mitigate the vandalism problem?
Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Dan Garry Associate Product Manager for Platform Wikimedia Foundation
I like the idea of more liberally (and perhaps automatically) giving out the right. As it stands, I'm not even sure who can give out editbugs other than Andre. In any case I understand it to be a very small number who can. For a start it would be nice if pretty much any active developer could. Perhaps even anyone with the editbugs right.
Automated solution would be even better. I suppose one could implement Dan's suggestion by having a script that sends part A of a token to your bugzilla email, part b to a your mediawiki email, and asks the user to produce both.
-bawolff On 2013-11-06 11:46 AM, "Dan Garry" dgarry@wikimedia.org wrote:
I don't want anything to stand in the way of good users
Perhaps something similar to autoconfirmed as Thehelpfulone suggested,
i.e.
X total edits across all Wikimedia projects (or on a single Wikimedia project), and account was created Y days ago. There are details to work through with that (e.g. how do we verify bugzilla user a@b.com owns the global account they say they do?), but I think it's a good approach.
Dan
On 6 November 2013 15:38, Rob Lanphier robla@wikimedia.org wrote:
On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride z@mzmcbride.com wrote:
Our Bugzilla installation at https://bugs.wikimedia.org/ currently restricts the capabilities of new users as a knee-jerk response to
prior
Bugzilla-related vandalism. There are further details at https://bugzilla.wikimedia.org/40497.
As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt
with
most of the aftermath of the attacks that we received that ultimately
led
to it being turned off. It was not a knee jerk response. We
temporarily
turned it off and turned it back on a few days later, only to have
dozens
(hundreds?) of bugs altered in a way that was not easily reversed.
In consulting with the Bugzilla developers (I believe I may have sent a public mail about this to their list), their answer was essentially that Bugzilla was never designed for giving editbugs to untrusted users, and that by doing so, we had what was coming to us.
We tried reversing it several times, and each time were rewarded with an arduous cleanup task. We gave up trying after months. So, calling it "kneejerk" is simply wrong. We had a determined vandal who may still be among us, and will likely exploit whatever loophole we open up.
Increasingly new users are making manual requests to be assigned to
bugs,
as they cannot edit others' bugs by default. This is problematic and disruptive to development efforts.
My suggestion is to re-add the "editbugs" user right to new users by default (revert the old settings adjustment). Otherwise, an acceptable workaround needs to be found.
I don't think we can pretend that the vandalism issue is solved,
because it
isn't. Bugzilla doesn't have the vandalism fighting tools that
MediaWiki
does.
We can certainly do something different than what we're doing, though.
It
should be easy to get editbugs; just not so easy that a vandal can get
it.
Anyone have any ideas how to mitigate the vandalism problem?
Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Dan Garry Associate Product Manager for Platform Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Nov 6, 2013 at 7:38 AM, Rob Lanphier robla@wikimedia.org wrote:
On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride z@mzmcbride.com wrote:
Our Bugzilla installation at https://bugs.wikimedia.org/ currently restricts the capabilities of new users as a knee-jerk response to prior Bugzilla-related vandalism. There are further details at https://bugzilla.wikimedia.org/40497.
As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt with most of the aftermath of the attacks that we received that ultimately led to it being turned off. It was not a knee jerk response. We temporarily turned it off and turned it back on a few days later, only to have dozens (hundreds?) of bugs altered in a way that was not easily reversed.
In consulting with the Bugzilla developers (I believe I may have sent a public mail about this to their list), their answer was essentially that Bugzilla was never designed for giving editbugs to untrusted users, and that by doing so, we had what was coming to us.
We tried reversing it several times, and each time were rewarded with an arduous cleanup task. We gave up trying after months. So, calling it "kneejerk" is simply wrong. We had a determined vandal who may still be among us, and will likely exploit whatever loophole we open up.
Increasingly new users are making manual requests to be assigned to bugs,
as they cannot edit others' bugs by default. This is problematic and disruptive to development efforts.
My suggestion is to re-add the "editbugs" user right to new users by default (revert the old settings adjustment). Otherwise, an acceptable workaround needs to be found.
I don't think we can pretend that the vandalism issue is solved, because it isn't. Bugzilla doesn't have the vandalism fighting tools that MediaWiki does.
We can certainly do something different than what we're doing, though. It should be easy to get editbugs; just not so easy that a vandal can get it.
Anyone have any ideas how to mitigate the vandalism problem?
How about we make editbugs self-granting? That is, if you've got editbugs you can give it to others (like we did with Coder a few years ago). It works pretty well, scales infinitely, and tends to protect itself against abuse.
If the vandal suddenly reappears, it's pretty easy to figure out who they are or who let them in at that point.
-Chad
On Wed, Nov 6, 2013 at 7:54 AM, Chad innocentkiller@gmail.com wrote:
How about we make editbugs self-granting? That is, if you've got editbugs you can give it to others (like we did with Coder a few years ago). It works pretty well, scales infinitely, and tends to protect itself against abuse.
If the vandal suddenly reappears, it's pretty easy to figure out who they are or who let them in at that point.
+∞ I endorse this notion.
-- brion
On 11/06/2013 04:54 PM, Chad wrote:
How about we make editbugs self-granting? That is, if you've got editbugs you can give it to others (like we did with Coder a few years ago). It works pretty well, scales infinitely, and tends to protect itself against abuse.
I agree with the others that the status quo is not a huge problem. Occasionally, people ask for editbugs, and they get it. It's still a obstacle; the question is just how significant.
Thus, I think this idea is worth trying.
If the vandal suddenly reappears, it's pretty easy to figure out who they are or who let them in at that point.
Yep. I'm assuming there is an easy to lookup log for this. There's still the possibility that vandals will be really disruptive, and do things like chains of editbugs, sleeper accounts, etc. But if so we can turn it off again, and/or require that people be stricter (on risk of losing their own editbugs), to stop the root of the chain.
Some kind of auto-confirmed (e.g. 5+ bug edits and 4 days) would be better (i.e. you have editbugs, and you're autoconfirmed, so you can grant), but I'm not sure how difficult that is to implement
Matt Flaschen
In general: I am happy to change Bugzilla settings, whatever is agreed on in the end.
On Wed, 2013-11-06 at 07:38 -0800, Rob Lanphier wrote:
On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride z@mzmcbride.com wrote:
Our Bugzilla installation at https://bugs.wikimedia.org/ currently restricts the capabilities of new users as a knee-jerk response to prior Bugzilla-related vandalism. There are further details at https://bugzilla.wikimedia.org/40497.
As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt with most of the aftermath of the attacks that we received that ultimately led to it being turned off. It was not a knee jerk response. We temporarily turned it off and turned it back on a few days later, only to have dozens (hundreds?) of bugs altered in a way that was not easily reversed.
Bugzilla does not allow centrally reverting all actions by a specific person: https://bugzilla.mozilla.org/show_bug.cgi?id=735213
In consulting with the Bugzilla developers (I believe I may have sent a public mail about this to their list), their answer was essentially that Bugzilla was never designed for giving editbugs to untrusted users, and that by doing so, we had what was coming to us.
[...]
We can certainly do something different than what we're doing, though. It should be easy to get editbugs; just not so easy that a vandal can get it.
Anyone have any ideas how to mitigate the vandalism problem?
Refering to the recent problem in Wikimedia Bugzilla, setting the assignee field is only possible when having "editbugs" permissions. There are no permissions which are more fine-grained and I could not find a request upstream asking for a specific "be able to change the assignee without editbugs permissions" request (plus docs suck anyway, see https://bugzilla.mozilla.org/show_bug.cgi?id=481859 ).
I have no good spontaneous idea how to solve this problem. My guess is hacking the code as described in http://www.bugzilla.org/docs/4.4/en/html/cust-change-permissions.html I've asked on the upstream mailing list: https://groups.google.com/forum/#!topic/mozilla.support.bugzilla/6GCB7ufa7nc
The wider picture regarding vandalism: Related unresolved upstream bugs refering to blocking IPs: https://bugzilla.mozilla.org/show_bug.cgi?id=904698 https://bugzilla.mozilla.org/show_bug.cgi?id=536110 Mozilla Bugzilla had a spam problem a few days ago, and they ended up temporarily disabling account creation for specific domains *manually*, instead of trying to fix it properly in https://bugzilla.mozilla.org/show_bug.cgi?id=467763
andre
On 11/06/2013 11:16 AM, Andre Klapper wrote:
Bugzilla does not allow centrally reverting all actions by a specific person: https://bugzilla.mozilla.org/show_bug.cgi?id=735213
Luckily, though, it does track actions by user. As a result, I was able to revert the vandalism. But it does seem like that ("revert all actions by this user") should be something in Bugzilla itself.
Mark.
Rob Lanphier wrote:
We tried reversing it several times, and each time were rewarded with an arduous cleanup task. We gave up trying after months. So, calling it "kneejerk" is simply wrong. We had a determined vandal who may still be among us, and will likely exploit whatever loophole we open up.
Okay, I apologize for using that term.
We can certainly do something different than what we're doing, though. It should be easy to get editbugs; just not so easy that a vandal can get it.
Okay, let's. I proposed reverting the settings change. You don't like that idea. Your turn. :-)
MZMcBride
On Wed, Nov 6, 2013 at 4:18 PM, MZMcBride z@mzmcbride.com wrote:
Rob Lanphier wrote:
We can certainly do something different than what we're doing, though. It
should be easy to get editbugs; just not so easy that a vandal can get it.
Okay, let's. I proposed reverting the settings change. You don't like that idea. Your turn. :-)
We keep the status quo. Your turn :-P
I like the idea of giving everyone who has editbugs the right to give other people the editbugs permission. That's certainly worth a try assuming it's possible to configure.
BTW, here's the original thread from when it got bad: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56816
A couple of relevant Bugzilla bugs come up in that thread: Bug 363346: "show activity should have an option to migrate or revert a set of changes" https://bugzilla.mozilla.org/show_bug.cgi?id=363346
Bug 704753: "Throttle new bug creation, comments, and modifications for some accounts" https://bugzilla.mozilla.org/show_bug.cgi?id=704753
If we had these two, we'd be golden for opening it all of the way back up. Even if we just had 704753, that could limit the scope of a cleanup effort quite a bit.
Rob
On Wed, Nov 6, 2013 at 10:04 PM, Rob Lanphier robla@wikimedia.org wrote:
I like the idea of giving everyone who has editbugs the right to give other people the editbugs permission. That's certainly worth a try assuming it's possible to configure.
I want to underscore this again. I think this is a great idea and I haven't seen any objections to it yet. Can we go ahead with this proposal?
(Even if we go further, this is a nice first step imho)
-Chad
On Thu, 07 Nov 2013 17:33:14 +0100, Chad innocentkiller@gmail.com wrote:
On Wed, Nov 6, 2013 at 10:04 PM, Rob Lanphier robla@wikimedia.org wrote:
I like the idea of giving everyone who has editbugs the right to give other people the editbugs permission. That's certainly worth a try assuming it's possible to configure.
I want to underscore this again. I think this is a great idea and I haven't seen any objections to it yet. Can we go ahead with this proposal?
This sounds like a great compromise. Please make it happen!
On Thu, 2013-11-07 at 08:33 -0800, Chad wrote:
On Wed, Nov 6, 2013 at 10:04 PM, Rob Lanphier robla@wikimedia.org wrote:
I like the idea of giving everyone who has editbugs the right to give other people the editbugs permission. That's certainly worth a try assuming it's possible to configure.
I want to underscore this again. I think this is a great idea and I haven't seen any objections to it yet. Can we go ahead with this proposal?
There seems to be sufficient support to grant users who have "editbugs" rights the permission to hand out (and revert) editbugs rights to/of other users.
If we did this, users with editbugs rights can go to "Links > Administration > Users", enter the email address of a user, and hand out editbugs to other users.
However, the right to hand out editbugs rights to other users cannot be handed out recursively: If I give user X the right to hand out editbugs permissions to other users, then user X can only give editbugs to user Y him/herself, but user Y will NOT automatically be able to hand out editbugs to user Z.
For the records: Currently 14744 Wikimedia Bugzilla users have editbugs permissions (so this is something to do via an SQL command instead of me clicking myself to death in Bugzilla's web interface).
andre
On Nov 7, 2013 6:27 PM, "Andre Klapper" aklapper@wikimedia.org wrote:
For the records: Currently 14744 Wikimedia Bugzilla users have editbugs permissions (so this is something to do via an SQL command instead of me clicking myself to death in Bugzilla's web interface).
I also generally support this. But maybe we can limit to only users that have done at least one or two actions in the last X months. Or exclude people that haven't logged in for a year. 14.7k sounds like a lot.
Also, what is the current method for marking bad users and making sure they don't get promoted? Like CentralAuth's lock.
After the first batch who can then make more people who can grant editbugs? is this going to be a regular automated thing? manually done each X weeks?
Also, I'm less clear about the remove editbugs form users part. That could be more restricted than granting.
Max, et al. what do you think?
-Jeremy
On Thu, Nov 7, 2013 at 6:02 PM, Jeremy Baron jeremy@tuxmachine.com wrote:
Also, what is the current method for marking bad users and making sure they don't get promoted? Like CentralAuth's lock.
Spammers can have their account set to "disabled" by any BZ admin. They'll get a disabled message when trying to login.
-Chad
wikitech-l@lists.wikimedia.org