Re: [Development] Setting the priority of bug reports created the Qt Support team
Before the transition to Qt being developed in the open via open governance, the Qt Support team back in Trolltech and later Nokia, would prioritize the bugs that were created, or at least handled, by them. Typically these would be bugs that were brought to our attention by commercial customers using Qt. As we know the bug fairly well at this point, and have an understanding of the impact it has on applications, then we were in a position to set a reasonable priority setting. Since the move to develop in the open via open governance, this has not been kept up, as it was back then not desired that the Qt Support team would continue this practice. What I would like to suggest that we do now is bring back this practice, so that the Qt Support team will set a priority on the bugs that it creates or handles, so that it makes things easier for the maintainers to actually see what issues are potentially a higher priority than the others. And in the case of the high priority issues, it will draw attention to them faster rather than them being picked up later on in the process. I have also discussed this with the developers inside Digia, and they see a need for getting help when triaging the bugs, so having the Qt Support team set a priority here would at least go some way to helping with that. Of course any priority set by the Qt Support team is intended to be a guideline, the maintainer would still be at liberty to change it if they disagree. Is there any comments, thoughts or concerns about this proposal? If I don't hear any objections, then we will move ahead with this starting within the next week. I know that there are still side discussions related to this, but there were no objections to the support team in Digia at least prioritizing the issues they create so we will start doing this as of today. Regards, Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting the priority of bug reports created the Qt Support team
On 19.02.13 18:25, Frederik Gladhorn frederik.gladh...@digia.com wrote: See also my mail from two weeks ago ([Development] issue tracker rights). I think we need to make a few more adjustments and really need more people with bug triaging rights. Actually, there is a good reminder, since there were others concerns with the way how bugs are currently triaged. Peter was commenting about labels, for example. I would like to bring up another aspect. We (Qt in BlackBerry) are strongly considering to move known Qt issues from an internal tracker into https://bugreports.qt-project.org/ and later on, redirect Qt related issues reported by BackBerry developers into BlackBerry https://bugreports.qt-project.org/ as well. Our motivation for this is very simple: keep Qt bugs going to one place and avoid fragmentation. Handling a few BlackBerry related issues which were already posted on https://bugreports.qt-project.org/, I started doubting if we can really use https://bugreports.qt-project.org/ for operations. The major problem is that the only what a normal user do is commenting on bugs. I know this topic is not directly related to the actual posting by Andy. I just wanted to raise my hand and underline that there are more triage related problems with https://bugreports.qt-project.org/ -- Vladimir Minenko Technical Manager, Qt http://developer.blackberry.com/qt +49 160 9898 3242 - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting the priority of bug reports created the Qt Support team
On Fri, 2013-02-22 at 12:15 +, Vladimir Minenko wrote: Our motivation for this is very simple: keep Qt bugs going to one place and avoid fragmentation. But is that really feasible? You'd have to make sure it's a general Qt problem first and not related to some interaction with Blackberry specifics. Or the Qt bugtracker is fine with having vendor-specific components. Handling a few BlackBerry related issues which were already posted on https://bugreports.qt-project.org/, I started doubting if we can really use https://bugreports.qt-project.org/ for operations. The major problem is that the only what a normal user do is commenting on bugs. I know this topic is not directly related to the actual posting by Andy. I just wanted to raise my hand and underline that there are more triage related problems with https://bugreports.qt-project.org/ It would be an interesting experiment to just open up the bug handling privileges for most JIRA accounts, if not even all. I would assume people will use their privileges with care although some might start playing the close/reopen bugs game. ciao Michael ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting the priority of bug reports created the Qt Support team
On sexta-feira, 22 de fevereiro de 2013 16.18.13, Michael Hasselmann wrote: On Fri, 2013-02-22 at 12:15 +, Vladimir Minenko wrote: Our motivation for this is very simple: keep Qt bugs going to one place and avoid fragmentation. But is that really feasible? You'd have to make sure it's a general Qt problem first and not related to some interaction with Blackberry specifics. Or the Qt bugtracker is fine with having vendor-specific components. That's no different from any other bug report where we must determine whether the problem lies in Qt code or in the underlying platform (e.g., bionic shortcomings), or whether it lies in the application itself or third-party Qt- based libraries (e.g., kdelibs). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting the priority of bug reports created the Qt Support team
Fredag 15. februar 2013 12.47.49 skrev Shaw Andy: Hi, Before the transition to Qt being developed in the open via open governance, the Qt Support team back in Trolltech and later Nokia, would prioritize the bugs that were created, or at least handled, by them. Typically these would be bugs that were brought to our attention by commercial customers using Qt. As we know the bug fairly well at this point, and have an understanding of the impact it has on applications, then we were in a position to set a reasonable priority setting. Since the move to develop in the open via open governance, this has not been kept up, as it was back then not desired that the Qt Support team would continue this practice. What I would like to suggest that we do now is bring back this practice, so that the Qt Support team will set a priority on the bugs that it creates or handles, so that it makes things easier for the maintainers to actually see what issues are potentially a higher priority than the others. And in the case of the high priority issues, it will draw attention to them faster rather than them being picked up later on in the process. I have also discussed this with the developers inside Digia, and they see a need for getting help when triaging the bugs, so having the Qt Support team set a priority here would at least go some way to helping with that. Of course any priority set by the Qt Support team is intended to be a guideline, the maintainer would still be at liberty to change it if they disagree. Is there any comments, thoughts or concerns about this proposal? If I don't hear any objections, then we will move ahead with this starting within the next week. See also my mail from two weeks ago ([Development] issue tracker rights). I think we need to make a few more adjustments and really need more people with bug triaging rights. Greetings Frederik Regards, Andy -- Andy Shaw, Head of Qt Support, Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Setting the priority of bug reports created the Qt Support team
Hi, Before the transition to Qt being developed in the open via open governance, the Qt Support team back in Trolltech and later Nokia, would prioritize the bugs that were created, or at least handled, by them. Typically these would be bugs that were brought to our attention by commercial customers using Qt. As we know the bug fairly well at this point, and have an understanding of the impact it has on applications, then we were in a position to set a reasonable priority setting. Since the move to develop in the open via open governance, this has not been kept up, as it was back then not desired that the Qt Support team would continue this practice. What I would like to suggest that we do now is bring back this practice, so that the Qt Support team will set a priority on the bugs that it creates or handles, so that it makes things easier for the maintainers to actually see what issues are potentially a higher priority than the others. And in the case of the high priority issues, it will draw attention to them faster rather than them being picked up later on in the process. I have also discussed this with the developers inside Digia, and they see a need for getting help when triaging the bugs, so having the Qt Support team set a priority here would at least go some way to helping with that. Of course any priority set by the Qt Support team is intended to be a guideline, the maintainer would still be at liberty to change it if they disagree. Is there any comments, thoughts or concerns about this proposal? If I don't hear any objections, then we will move ahead with this starting within the next week. Regards, Andy -- Andy Shaw, Head of Qt Support, Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting the priority of bug reports created the Qt Support team
On Fri, Feb 15, 2013 at 4:47 AM, Shaw Andy andy.s...@digia.com wrote: Hi, Before the transition to Qt being developed in the open via open governance, the Qt Support team back in Trolltech and later Nokia, would prioritize the bugs that were created, or at least handled, by them. Typically these would be bugs that were brought to our attention by commercial customers using Qt. As we know the bug fairly well at this point, and have an understanding of the impact it has on applications, then we were in a position to set a reasonable priority setting. Since the move to develop in the open via open governance, this has not been kept up, as it was back then not desired that the Qt Support team would continue this practice. What I would like to suggest that we do now is bring back this practice, so that the Qt Support team will set a priority on the bugs that it creates or handles, so that it makes things easier for the maintainers to actually see what issues are potentially a higher priority than the others. And in the case of the high priority issues, it will draw attention to them faster rather than them being picked up later on in the process. I have also discussed this with the developers inside Digia, and they see a need for getting help when triaging the bugs, so having the Qt Support team set a priority here would at least go some way to helping with that. Of course any priority set by the Qt Support team is intended to be a guideline, the maintainer would still be at liberty to change it if they disagree. I assume you mean that any approver would still be at liberty to edit the priority if they disagree, basically that there's nothing special about the priority just because it was set by Qt Support. Then there's just the theoretical problem of non-approvers setting bug priorities, which is that most people think their bugs are top priority. I'm pretty sure the Qt Support team is sensible enough that they don't do that, so I think it would be helpful for them to be setting (initial) priorities. It would be nice to expand the concept to something more general, like a 'trusted triagers' status, but that can come as a later step. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting the priority of bug reports created the Qt Support team
[snip] What I would like to suggest that we do now is bring back this practice, so that the Qt Support team will set a priority on the bugs that it creates or handles, so that it makes things easier for the maintainers to actually see what issues are potentially a higher priority than the others. And in the case of the high priority issues, it will draw attention to them faster rather than them being picked up later on in the process. I have also discussed this with the developers inside Digia, and they see a need for getting help when triaging the bugs, so having the Qt Support team set a priority here would at least go some way to helping with that. Of course any priority set by the Qt Support team is intended to be a guideline, the maintainer would still be at liberty to change it if they disagree. I assume you mean that any approver would still be at liberty to edit the priority if they disagree, basically that there's nothing special about the priority just because it was set by Qt Support. Yes, that is my intention, it should only be seen as a guide based on the person who triaged the issue since the person creating it would have verified the bug before having created it in this case. But if an approver disagrees then that is up to them and therefore it can be changed as appropriate. Then there's just the theoretical problem of non-approvers setting bug priorities, which is that most people think their bugs are top priority. I'm pretty sure the Qt Support team is sensible enough that they don't do that, so I think it would be helpful for them to be setting (initial) priorities. It would be nice to expand the concept to something more general, like a 'trusted triagers' status, but that can come as a later step. I agree, long term having such a group would be good because there will always be untriaged bugs that come in from other sources currently. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting the priority of bug reports created the Qt Support team
On Fri, Feb 15, 2013 at 10:47 PM, Shaw Andy andy.s...@digia.com wrote: Before the transition to Qt being developed in the open via open governance, the Qt Support team back in Trolltech and later Nokia, would prioritize the bugs that were created, or at least handled, by them. Typically these would be bugs that were brought to our attention by commercial customers using Qt. As we know the bug fairly well at this point, and have an understanding of the impact it has on applications, then we were in a position to set a reasonable priority setting. Since the move to develop in the open via open governance, this has not been kept up, as it was back then not desired that the Qt Support team would continue this practice. What I would like to suggest that we do now is bring back this practice, so that the Qt Support team will set a priority on the bugs that it creates or handles, so that it makes things easier for the maintainers to actually see what issues are potentially a higher priority than the others. And in the case of the high priority issues, it will draw attention to them faster rather than them being picked up later on in the process. I have also discussed this with the developers inside Digia, and they see a need for getting help when triaging the bugs, so having the Qt Support team set a priority here would at least go some way to helping with that. Of course any priority set by the Qt Support team is intended to be a guideline, the maintainer would still be at liberty to change it if they disagree. Sounds like a good idea to me. -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
