On 11 April 2013 04:08, Abhinandan Prateek <abhinandan.prat...@citrix.com>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" -- NS
