[Gluster-users] [Gluster-devel] Our plan to get bugs fixed quicker, and features implemented sooner

[Lalatendu Mohanty]

On 08/22/2014 01:20 PM, Pranith Kumar Karampuri wrote:
>
> On 08/22/2014 11:46 AM, Joe Julian wrote:
>> adding the "correct" gluster-devel to this.
>>
>> On 8/21/2014 10:55 PM, Joe Julian wrote:
>>> There have been times that I, as a user and a front-line supporter, 
>>> have marked a bug with the urgency that I think it deserves - based 
>>> on my own knowledge as well as feedback from other users - only to 
>>> have that urgency lowered to normal because a developer who doesn't 
>>> experience the urgency we do as users, deemed it so.
> Actually developers/assignees are not allowed to change severity, 
> never (Something that I learnt an year back. May be some developers 
> don't even know about it :-( ). Only priority is something that can be 
> lowered by the assignee. In my experience this happens for severe bugs 
> as well when the steps to re-create the bug are not there or logs are 
> not enough to find the root cause etc.
>>>
>>> Granted, there have also been many occasions where I didn't set the 
>>> urgency and my bug has been treated as if it was a message from 
>>> beyond the natural realm, for which I am truly grateful.
> Because the message _is_ from beyond natural realm ;-)
>>>
>>> When I set the urgency, I try to consider more than just my own 
>>> current needs (though often they're truly quite urgent) and look at 
>>> potential for data loss, likelihood to encounter the bug during 
>>> normal operations, and feedback from other users who have (usually) 
>>> encountered the same bug. To have all that forethought discarded is 
>>> disheartening. For that reason, I never set the urgency of any of my 
>>> bugs any more.
> I guess it would be better if you could raise it in devel mailing list 
> rather that not setting the urgency anymore :-(.
>>>
>>> I would be willing to participate in triage, but I would expect the 
>>> same rigidness in changing an urgency as there is in getting a 
>>> change accepted. The developer who wants to change the urgency 
>>> should be expected to argue his case, not simply change it.
> +1
>
> Pranith

It would good if we can update the triage wiki page [1] to have right 
criteria/information about changing Severity and Priority. We should 
treat the wiki page as our policy document.

http://www.gluster.org/community/documentation/index.php/Bug_triage

-Lala
>>>
>>> On 8/21/2014 12:12 AM, Lalatendu Mohanty wrote:
>>>> I hope the subject line have increased your curiosity to go through 
>>>> the email :).
>>>>
>>>> As a community, we are looking for contributors for GlusterFS bug 
>>>> triage and hopefully this mail will give you enough motivation for it.
>>>>
>>>> As mentioned in the subject , bug triage will help to get bugs 
>>>> fixed quicker, and features implemented sooner. If you are not sure 
>>>> what bug triage means, please refer the gluster wiki page [1] for 
>>>> bug triage.
>>>>
>>>> Here are few questions and answers to help you if this is something 
>>>> you should do.
>>>>
>>>>   * Q: Why we need to do bug triage?
>>>>   * A: It reduces the time between reporting a bug and the
>>>>     availability of a fix enormously.
>>>>       o Because many developers have bad response times for new
>>>>         bugs that are not pointed out to them. When well triaged
>>>>         bugs get assigned to right developers, the response time
>>>>         improves.
>>>>       o Also developers work mainly on writing bug fixes and
>>>>         implementing new features. Which in turn results in to
>>>>         spending (too little) time on bug triaging.
>>>>
>>>>
>>>>   * Q: I am just a GlusterFS user. Why bug triage will help me?
>>>>   * A: It will increase your understanding of GlusterFS, current
>>>>     issues in GlusterFS, increase the interaction between
>>>>     developers, community and triager. It will also help filing
>>>>     better bugs too. The better the bug report, the easier it is
>>>>     for a developer to write a fix.
>>>>
>>>>
>>>>   * Q: Do you run GlusterFS in production?
>>>>   * A: If your answer is yes, then bug triage is the right platform
>>>>     for you to raise the importance of bugs. Bug triage will also
>>>>     help you know existing issues in the version of GlusterFS you
>>>>     are using, help you to know existing issues in a new feature.
>>>>     So you will be in a better position to decide if a feature is
>>>>     production ready or not.
>>>>
>>>>
>>>>   * Q: I want to contribute to GlusterFS. Will bug triage help?
>>>>   * A: Yes, it is an awesome place to start. You will get to know
>>>>     about all the components in GlusterFS along with issues in each
>>>>     of them. This knowledge will help you to do better testing,
>>>>     development (bug fixing) etc. Also you will interact with
>>>>     developers while triaging bugs. You can use these interactions
>>>>     to ask more detailed questions.
>>>>
>>>>
>>>>   * Q: How can I triage bugs of GlusterFS?
>>>>   * A: The wiki page [1] is the right place start. We are starting
>>>>     up a bi-weekly/weekly triage meeting in #gluster-meeting on
>>>>     Freenode. There would be another mail with details about the
>>>>     meeting. You can join the meeting and interact with other triagers.
>>>>
>>>> Please don't hesitate to hit the reply button if you have any 
>>>> question on this. We would love to hear your suggestions/feed back :).
>>>>
>>>> [1] http://www.gluster.org/community/documentation/index.php/Bug_triage
>>>>
>>>> Thanks,
>>>> On behalf of the bug triage team
>>>> #gluster-dev, #gluster on Freenode
>>>>
>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140822/77a61de3/attachment.html>