cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [DISCUSS] Don't assign tickets to people when triaging
Date Thu, 11 Apr 2013 11:16:40 GMT
On 11 April 2013 04:08, Abhinandan Prateek <>wrote:

> Now is it wrong to ask the community members who have expertise on UI to
> fix it, in a bid to help Chip get the release out ?

It is certainly not wrong to co-ordinate with people in an effort to ship a
release. (I would point out, however, that it is not Chip getting the
release out. It is the community. But maybe I am misinterpreting your
remark here...)

2. Assign a bug that is open for more than 3 days and none of the
> community member has shown interest in picking it up. This period can vary
> depending on how close a branch where bug is noted is close to a release.

Three days?

That is a very short period of time, when you consider the size of our JIRA
queue, and the average timespan of a ticket.

I really don't see why bugs that are not on the critical path of a release
should be assigned at all. As has already been pointed out several times in
this thread, this is an exclusionary practice which is likely to put off
new contributions to the project. It will calcify the existing structure
and roles, and will hamper CloudStack's ability to grow as a project.

I don't understand why non-critical bugs cannot be categorised into
components. And then engineers can pick up items of the component backlogs
as they become free or want to work on CloudStack. This sort of approach is
inclusionary. Anybody can go to JIRA and click on one of the component
reports, and just take a ticket, and start working on it. (Without having
to contact the person it is "assigned" to to ask if they may start on it.
Which, in reality, nobody is going to to do.)

I also reject the idea that engineers need tickets assigned to them as
either a) some sort of communication method, or b) some way to spur them
into action. Firstly, we have the mailing list as a communication method.
If you want a particular set of bugs to be worked on, or whatever, then
post a message to the list, and ask for participation. Secondly, we should
not be spurring anybody into action. This is a volunteer project, and
people contribute as and when they can. They should not be managed like an
employee would be managed. Which is why it's so important that we build
structures that are open to chaotic volunteer efforts.

If $company is employing people to work on CloudStack, and wants to spur
its employees into action around a certain feature or component, then that
is fine. But this activity must be kept away from the lists. Perhaps have
$company internal email threads where you ask people to focus on things.
Any time that activity leaks on to the list, it sends the wrong message
about how to participate in the project, and sends the wrong message about
$company's relationship to the project.

> 3. Assign or request to community for picking up a bug if it is blocking
> the work that a community member may be working on.

Again, this is presumptuous. There is no minimum level of participation. So
saying "Bob, this is your bug, so fix it, because it is blocking me" is the
wrong attitude to take. Instead, we should be using every opportunity we
have, every construct we build, as a way to invite further participation
from the community. A better approach would be to mark the bug as blocking
some other work, and then post a note to the list saying "this bug is
blocking me, can I have some help with it please?" In an email like that,
feel free to CC the engineers you expect might want to / be able to help
out, or mention them by name. But don't make a habit of saying "Bob, this
bug is blocking me, can you fix it" when you could say "this bug is
blocking me, can someone fix it? /cc Bob"


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message