On 11/06/2013 07:24 AM, Petr Bena wrote: 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 Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

On 11/06/2013 04:24 PM, MZMcBride 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? 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. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

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(a)gmail.com> wrote: -- (http://cscott.net)

C. Scott Ananian wrote: 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: 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: Okay. As to your other questions, I'm confident we'll be able to figure out the logistical details, if needed. MZMcBride

On Fri, Nov 8, 2013 at 2:09 PM, Steven Walling <steven.walling(a)gmail.com>wrote;wrote: Not all teams have drank the Mingle Kool-Aid yet ;-) -Chad

On Fri, Nov 8, 2013 at 2:14 PM, Steven Walling <steven.walling(a)gmail.com>wrote;wrote: People may use it. I don't. I basically ignore assignee/status/priority fields. -Chad

On Fri, Nov 8, 2013 at 2:14 PM, Steven Walling <steven.walling(a)gmail.com> wrote: Yes. Rob

On Sat, Nov 9, 2013 at 1:24 AM, Matthew Flaschen <mflaschen(a)wikimedia.org>wrote;wrote: 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. 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: 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.) 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

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, 2013-11-09 at 10:22 -0400, MZMcBride wrote: 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 -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

On Sat, 2013-11-09 at 09:40 -0500, C. Scott Ananian wrote: 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 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 | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

Marcin Cieslak wrote: 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 08:28 -0800, Quim Gil wrote: 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 -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

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(a)wikimedia.org> wrote: -- (http://cscott.net)

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(a)wikimedia.org> wrote: -- Dan Garry Associate Product Manager for Platform Wikimedia Foundation

On Wed, Nov 6, 2013 at 7:38 AM, Rob Lanphier <robla(a)wikimedia.org> 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. -Chad

On 11/06/2013 04:54 PM, Chad wrote: 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. 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

On 11/06/2013 11:16 AM, Andre Klapper wrote: 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.

On Wed, Nov 6, 2013 at 4:18 PM, MZMcBride <z(a)mzmcbride.com> wrote: 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 Thu, 07 Nov 2013 17:33:14 +0100, Chad <innocentkiller(a)gmail.com> wrote: This sounds like a great compromise. Please make it happen! -- Matma Rex

On Nov 7, 2013 6:27 PM, "Andre Klapper" <aklapper(a)wikimedia.org> wrote: 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