[general] JIRA issue search problem

[Alexey Petrenko <al...@gmail.com>]

Guys,

this thread is created as a result of  "[general] Wise JIRA processing" thread.
Few people concerned that it is difficult to find a free JIRA issue to
work on. And I agree with this concern.

Committer can assign the issue to himself when he is starting to
investigate the issue. And others can filter for non-assigned issues.
But non-committer can not set any flag for the issue to let other
people to filter.

I do not think that granting possibility to non-committers to assign
issues is a good idea since it will remove the possibility for
committers to filter non-assigned bugs to commit.

I suggest to let non-committers to set and unset "in progress"
property. In this case non-committer will add comment to the issue
that he started investigation and will set the "in progress" property.
And others will can filter issues by this field.

Thoughts?

Geir, is this possible at all? :)

SY, Alexey

Re: [general] JIRA issue search problem

[Salikh Zakirov <Sa...@Intel.com>]

Alexey Petrenko wrote:
> But most of 700 open issues in JIRA now are rather simple issues. Like
> wrong exception,  no exception and so on. 
> ...
> And it's real pain to open tens of simple issues to check if somebody
> already working on it. Impossibility of setting "patch available" flag
> makes the situation even worse because you should check already fixed
> issues too while you find some free to fix issue.

Thanks a lot for a good explanation.

> So adding additional assignee field will help to sort the issues and
> will make life for all contributors easier. From the other hand it
> will not bring any troubles in fixing complicated issues by teams. 

Understood and agreed.

Re: [general] JIRA issue search problem

[Alexey Petrenko <al...@gmail.com>]

18 Dec 2006 14:01:27 +0600, Egor Pasko <eg...@gmail.com>:
> On the 0x240 day of Apache Harmony Alexey Petrenko wrote:
> > Salikh,
> >
> > there is some truth in your words...
> > Yes, if we got a big issue then nothing strange in fixing it by 2, 3
> > or 10 people. And fix will probably appear faster and will be better.
> >
> > But most of 700 open issues in JIRA now are rather simple issues. Like
> > wrong exception,  no exception and so on. How many people will we need
> > to add an NPE check? 2, 3 or 10? There is an old joke: "How many
> > programmers do you need to change the lamp?" :)
> > And it's real pain to open tens of simple issues to check if somebody
> > already working on it. Impossibility of setting "patch available" flag
> > makes the situation even worse because you should check already fixed
> > issues too while you find some free to fix issue.
>
> That can be partially solved by pressing the "watch it" button for the
> issue you want to track. You will get the notifications on all the
> changes of watched issues by email. I use it regularly and it helps.
>
> If you had a good mail client that could filter email messages by the
> "[Patch Available]" substring in email _contents_, then you could
> easily get notifications of patch availibility for issues you are
> interested in.
I did not get your idea.
I'm interested to find free-to-fix issue. This means issue: 1. nobody
works on it, 2. It has no patch.
How "watch it" option will help in this?


> IMHO, this is good that only authors and comitters can set the "Patch
> Available" status. It induces a certain level of responsibility for
> JIRA owners to track the issues, review the patches, try them and
> respond.
Yes, I also like this approach more...
But from the other hand we can try free "patch available" setting to
see how it will work.

SY, Alexey

>
> > So adding additional assignee field will help to sort the issues and
> > will make life for all contributors easier. From the other hand it
> > will not bring any troubles in fixing complicated issues by teams.
> >
> > Is it a problem of contributors or managers? I'm not a manger...
> > yet... :) So I do not know is it important for them or not. I've never
> > heard any questions from my manager about JIRA processing.
> > Contributors? I'm, as a Harmony contributor, has a problem with
> > searching issues. I've asked few Harmony contributors around and they
> > supported my vision.
> > So I would say that there is a problem for Harmony contributors and I
> > know nothing about managers.
> >
> > SY, Alexey
> >
> > 2006/12/15, Salikh Zakirov <Sa...@intel.com>:
> > > Original problem statement was formulated by Mikhail:
> > > > For example, if the JIRA is not assigned then there is no simple way to
> > > > understand if there's activity in there except opening it in web-browser and
> > > > reading comments.
> > >
> > > I would argue that anyone who is really going to work on an issue, will
> > > definitely want to read through issue comments carefully, so this is not
> > > a problem for contributors.
> > >
> > > Rather, this is a problem of managers of employees assigned to work
> > > on the Harmony project, as they (managers) do not have good means to monitor
> > > what issues engineers work on.
> > >
> > > > Only committers could modify the status of JIRAs and put them "In progress"
> > > > mode. As we have not so many committers they could not monitor large number
> > > > of open JIRA.
> > >
> > > From the point of view of open-source community (set aside corporate culture
> > > etc.), there is no difference between "unassigned" and "in progress" issue,
> > > as this basically means that the fix is still not available.
> > >
> > > And if anyone _really_ interested in fixing a problem, then reading comments
> > > and interacting with others interested in the same problem is *good*.
> > > It facilitates better patch and design review, and overall leads to a better
> > > software quality.
> > >
> > > However, several engineers working on the same problem is perceived as
> > > an inefficiency in corporate setting, and thus is stated as a problem.
> > >
> > > Thus, the second problem is also induced by _sponsoring corporations_.
> > >
> > > In short, both Harmony contributors and committers (with "Harmony hat on") have
> > > *none* of the stated above problems.
> > > It is managers of sponsoring corporations that need improvement in JIRA
> > > searching capabilities.
> > >
> > > I am not suggesting that Harmony should ignore wishes of the managers
> > > of sponsoring corporations, but I think that the problem could be solved
> > > much better if the problem and its justification is stated clearly,
> > > without alluding to contributor problems which do not really exist.
> > >
> > >
> > > But then, with current JIRA configurations, some problems do exist,
> > > which could be addressed tweaking JIRA configuration, but now requires
> > > mail communication. This is something that I encountered in *my practice*:
> > >
> > > * When submitting a patch for an issue filed by someone else, the committer
> > > attention will not be attracted automatically, because I can't set 'patch
> > > available' status. The workaround for this is to create subtask for the
> > > fixed issue, and attach patch to that subtask, with 'patch available' set.
> > > IMHO, this workaround is good enough.
> > >
> > > * When searching for issues related to particular component, I can easily
> > > miss some of them, because '[component]' notation is not universally used
> > > (now and then someone forgets to add component), and since only committers
> > > and submitters are allowed to edit jira summary and categories, cleaning
> > > up issues requires mail communications.
> > >
> > > IMHO, None of this is critical, and may be left as is.
> > >
> > > > How about the following structure:
> > > > 1) Contributor assignee field for everybody (if a committer working on
> > > > patch preparation he/she should use this field). Also, for example, if it's
> > > > non-null then the status of unresolved JIRA is "In progress" automatically.
> > > > 2) Committer assignee field for committers
> > >
> > > These are not really needed neither to committers, nor to contributors.
> > > It will not do any harm though, and definitely will be useful
> > > for sponsoring corporations.
> > >
> > > So, +0
> > >
> > > > 3) Everybody could set "Patch available" tag (another option is: JIRA
> > > > contributor assignee, JIRA author or committers coud set this tag)
> > >
> > > This will make submitting patches easier for contributors.
> > > +1
> > >
> > >
> >
>
> --
> Egor Pasko
>
>

Re: [general] JIRA issue search problem

[Egor Pasko <eg...@gmail.com>]

On the 0x240 day of Apache Harmony Alexey Petrenko wrote:
> Salikh,
> 
> there is some truth in your words...
> Yes, if we got a big issue then nothing strange in fixing it by 2, 3
> or 10 people. And fix will probably appear faster and will be better.
> 
> But most of 700 open issues in JIRA now are rather simple issues. Like
> wrong exception,  no exception and so on. How many people will we need
> to add an NPE check? 2, 3 or 10? There is an old joke: "How many
> programmers do you need to change the lamp?" :)
> And it's real pain to open tens of simple issues to check if somebody
> already working on it. Impossibility of setting "patch available" flag
> makes the situation even worse because you should check already fixed
> issues too while you find some free to fix issue.

That can be partially solved by pressing the "watch it" button for the
issue you want to track. You will get the notifications on all the
changes of watched issues by email. I use it regularly and it helps.

If you had a good mail client that could filter email messages by the
"[Patch Available]" substring in email _contents_, then you could
easily get notifications of patch availibility for issues you are
interested in.

IMHO, this is good that only authors and comitters can set the "Patch
Available" status. It induces a certain level of responsibility for
JIRA owners to track the issues, review the patches, try them and
respond.

> So adding additional assignee field will help to sort the issues and
> will make life for all contributors easier. From the other hand it
> will not bring any troubles in fixing complicated issues by teams.
> 
> Is it a problem of contributors or managers? I'm not a manger...
> yet... :) So I do not know is it important for them or not. I've never
> heard any questions from my manager about JIRA processing.
> Contributors? I'm, as a Harmony contributor, has a problem with
> searching issues. I've asked few Harmony contributors around and they
> supported my vision.
> So I would say that there is a problem for Harmony contributors and I
> know nothing about managers.
> 
> SY, Alexey
> 
> 2006/12/15, Salikh Zakirov <Sa...@intel.com>:
> > Original problem statement was formulated by Mikhail:
> > > For example, if the JIRA is not assigned then there is no simple way to
> > > understand if there's activity in there except opening it in web-browser and
> > > reading comments.
> >
> > I would argue that anyone who is really going to work on an issue, will
> > definitely want to read through issue comments carefully, so this is not
> > a problem for contributors.
> >
> > Rather, this is a problem of managers of employees assigned to work
> > on the Harmony project, as they (managers) do not have good means to monitor
> > what issues engineers work on.
> >
> > > Only committers could modify the status of JIRAs and put them "In progress"
> > > mode. As we have not so many committers they could not monitor large number
> > > of open JIRA.
> >
> > From the point of view of open-source community (set aside corporate culture
> > etc.), there is no difference between "unassigned" and "in progress" issue,
> > as this basically means that the fix is still not available.
> >
> > And if anyone _really_ interested in fixing a problem, then reading comments
> > and interacting with others interested in the same problem is *good*.
> > It facilitates better patch and design review, and overall leads to a better
> > software quality.
> >
> > However, several engineers working on the same problem is perceived as
> > an inefficiency in corporate setting, and thus is stated as a problem.
> >
> > Thus, the second problem is also induced by _sponsoring corporations_.
> >
> > In short, both Harmony contributors and committers (with "Harmony hat on") have
> > *none* of the stated above problems.
> > It is managers of sponsoring corporations that need improvement in JIRA
> > searching capabilities.
> >
> > I am not suggesting that Harmony should ignore wishes of the managers
> > of sponsoring corporations, but I think that the problem could be solved
> > much better if the problem and its justification is stated clearly,
> > without alluding to contributor problems which do not really exist.
> >
> >
> > But then, with current JIRA configurations, some problems do exist,
> > which could be addressed tweaking JIRA configuration, but now requires
> > mail communication. This is something that I encountered in *my practice*:
> >
> > * When submitting a patch for an issue filed by someone else, the committer
> > attention will not be attracted automatically, because I can't set 'patch
> > available' status. The workaround for this is to create subtask for the
> > fixed issue, and attach patch to that subtask, with 'patch available' set.
> > IMHO, this workaround is good enough.
> >
> > * When searching for issues related to particular component, I can easily
> > miss some of them, because '[component]' notation is not universally used
> > (now and then someone forgets to add component), and since only committers
> > and submitters are allowed to edit jira summary and categories, cleaning
> > up issues requires mail communications.
> >
> > IMHO, None of this is critical, and may be left as is.
> >
> > > How about the following structure:
> > > 1) Contributor assignee field for everybody (if a committer working on
> > > patch preparation he/she should use this field). Also, for example, if it's
> > > non-null then the status of unresolved JIRA is "In progress" automatically.
> > > 2) Committer assignee field for committers
> >
> > These are not really needed neither to committers, nor to contributors.
> > It will not do any harm though, and definitely will be useful
> > for sponsoring corporations.
> >
> > So, +0
> >
> > > 3) Everybody could set "Patch available" tag (another option is: JIRA
> > > contributor assignee, JIRA author or committers coud set this tag)
> >
> > This will make submitting patches easier for contributors.
> > +1
> >
> >
> 

-- 
Egor Pasko

Re: [general] JIRA issue search problem

[Alexey Petrenko <al...@gmail.com>]

Salikh,

there is some truth in your words...
Yes, if we got a big issue then nothing strange in fixing it by 2, 3
or 10 people. And fix will probably appear faster and will be better.

But most of 700 open issues in JIRA now are rather simple issues. Like
wrong exception,  no exception and so on. How many people will we need
to add an NPE check? 2, 3 or 10? There is an old joke: "How many
programmers do you need to change the lamp?" :)
And it's real pain to open tens of simple issues to check if somebody
already working on it. Impossibility of setting "patch available" flag
makes the situation even worse because you should check already fixed
issues too while you find some free to fix issue.

So adding additional assignee field will help to sort the issues and
will make life for all contributors easier. From the other hand it
will not bring any troubles in fixing complicated issues by teams.

Is it a problem of contributors or managers? I'm not a manger...
yet... :) So I do not know is it important for them or not. I've never
heard any questions from my manager about JIRA processing.
Contributors? I'm, as a Harmony contributor, has a problem with
searching issues. I've asked few Harmony contributors around and they
supported my vision.
So I would say that there is a problem for Harmony contributors and I
know nothing about managers.

SY, Alexey

2006/12/15, Salikh Zakirov <Sa...@intel.com>:
> Original problem statement was formulated by Mikhail:
> > For example, if the JIRA is not assigned then there is no simple way to
> > understand if there's activity in there except opening it in web-browser and
> > reading comments.
>
> I would argue that anyone who is really going to work on an issue, will
> definitely want to read through issue comments carefully, so this is not
> a problem for contributors.
>
> Rather, this is a problem of managers of employees assigned to work
> on the Harmony project, as they (managers) do not have good means to monitor
> what issues engineers work on.
>
> > Only committers could modify the status of JIRAs and put them "In progress"
> > mode. As we have not so many committers they could not monitor large number
> > of open JIRA.
>
> From the point of view of open-source community (set aside corporate culture
> etc.), there is no difference between "unassigned" and "in progress" issue,
> as this basically means that the fix is still not available.
>
> And if anyone _really_ interested in fixing a problem, then reading comments
> and interacting with others interested in the same problem is *good*.
> It facilitates better patch and design review, and overall leads to a better
> software quality.
>
> However, several engineers working on the same problem is perceived as
> an inefficiency in corporate setting, and thus is stated as a problem.
>
> Thus, the second problem is also induced by _sponsoring corporations_.
>
> In short, both Harmony contributors and committers (with "Harmony hat on") have
> *none* of the stated above problems.
> It is managers of sponsoring corporations that need improvement in JIRA
> searching capabilities.
>
> I am not suggesting that Harmony should ignore wishes of the managers
> of sponsoring corporations, but I think that the problem could be solved
> much better if the problem and its justification is stated clearly,
> without alluding to contributor problems which do not really exist.
>
>
> But then, with current JIRA configurations, some problems do exist,
> which could be addressed tweaking JIRA configuration, but now requires
> mail communication. This is something that I encountered in *my practice*:
>
> * When submitting a patch for an issue filed by someone else, the committer
> attention will not be attracted automatically, because I can't set 'patch
> available' status. The workaround for this is to create subtask for the
> fixed issue, and attach patch to that subtask, with 'patch available' set.
> IMHO, this workaround is good enough.
>
> * When searching for issues related to particular component, I can easily
> miss some of them, because '[component]' notation is not universally used
> (now and then someone forgets to add component), and since only committers
> and submitters are allowed to edit jira summary and categories, cleaning
> up issues requires mail communications.
>
> IMHO, None of this is critical, and may be left as is.
>
> > How about the following structure:
> > 1) Contributor assignee field for everybody (if a committer working on
> > patch preparation he/she should use this field). Also, for example, if it's
> > non-null then the status of unresolved JIRA is "In progress" automatically.
> > 2) Committer assignee field for committers
>
> These are not really needed neither to committers, nor to contributors.
> It will not do any harm though, and definitely will be useful
> for sponsoring corporations.
>
> So, +0
>
> > 3) Everybody could set "Patch available" tag (another option is: JIRA
> > contributor assignee, JIRA author or committers coud set this tag)
>
> This will make submitting patches easier for contributors.
> +1
>
>

Re: [general] JIRA issue search problem

[Alexei Zakharov <al...@gmail.com>]

+1 to all that Salikh just has said.

Regards,

2006/12/15, Salikh Zakirov <Sa...@intel.com>:
> Original problem statement was formulated by Mikhail:
> > For example, if the JIRA is not assigned then there is no simple way to
> > understand if there's activity in there except opening it in web-browser and
> > reading comments.
>
> I would argue that anyone who is really going to work on an issue, will
> definitely want to read through issue comments carefully, so this is not
> a problem for contributors.
>
> Rather, this is a problem of managers of employees assigned to work
> on the Harmony project, as they (managers) do not have good means to monitor
> what issues engineers work on.
>
> > Only committers could modify the status of JIRAs and put them "In progress"
> > mode. As we have not so many committers they could not monitor large number
> > of open JIRA.
>
> From the point of view of open-source community (set aside corporate culture
> etc.), there is no difference between "unassigned" and "in progress" issue,
> as this basically means that the fix is still not available.
>
> And if anyone _really_ interested in fixing a problem, then reading comments
> and interacting with others interested in the same problem is *good*.
> It facilitates better patch and design review, and overall leads to a better
> software quality.
>
> However, several engineers working on the same problem is perceived as
> an inefficiency in corporate setting, and thus is stated as a problem.
>
> Thus, the second problem is also induced by _sponsoring corporations_.
>
> In short, both Harmony contributors and committers (with "Harmony hat on") have
> *none* of the stated above problems.
> It is managers of sponsoring corporations that need improvement in JIRA
> searching capabilities.
>
> I am not suggesting that Harmony should ignore wishes of the managers
> of sponsoring corporations, but I think that the problem could be solved
> much better if the problem and its justification is stated clearly,
> without alluding to contributor problems which do not really exist.
>
>
> But then, with current JIRA configurations, some problems do exist,
> which could be addressed tweaking JIRA configuration, but now requires
> mail communication. This is something that I encountered in *my practice*:
>
> * When submitting a patch for an issue filed by someone else, the committer
> attention will not be attracted automatically, because I can't set 'patch
> available' status. The workaround for this is to create subtask for the
> fixed issue, and attach patch to that subtask, with 'patch available' set.
> IMHO, this workaround is good enough.
>
> * When searching for issues related to particular component, I can easily
> miss some of them, because '[component]' notation is not universally used
> (now and then someone forgets to add component), and since only committers
> and submitters are allowed to edit jira summary and categories, cleaning
> up issues requires mail communications.
>
> IMHO, None of this is critical, and may be left as is.
>
> > How about the following structure:
> > 1) Contributor assignee field for everybody (if a committer working on
> > patch preparation he/she should use this field). Also, for example, if it's
> > non-null then the status of unresolved JIRA is "In progress" automatically.
> > 2) Committer assignee field for committers
>
> These are not really needed neither to committers, nor to contributors.
> It will not do any harm though, and definitely will be useful
> for sponsoring corporations.
>
> So, +0
>
> > 3) Everybody could set "Patch available" tag (another option is: JIRA
> > contributor assignee, JIRA author or committers coud set this tag)
>
> This will make submitting patches easier for contributors.
> +1



-- 
Alexei Zakharov,
Intel ESSD

Re: [general] JIRA issue search problem

[Salikh Zakirov <Sa...@Intel.com>]

Original problem statement was formulated by Mikhail:
> For example, if the JIRA is not assigned then there is no simple way to
> understand if there's activity in there except opening it in web-browser and
> reading comments.

I would argue that anyone who is really going to work on an issue, will
definitely want to read through issue comments carefully, so this is not
a problem for contributors.

Rather, this is a problem of managers of employees assigned to work
on the Harmony project, as they (managers) do not have good means to monitor
what issues engineers work on.

> Only committers could modify the status of JIRAs and put them "In progress"
> mode. As we have not so many committers they could not monitor large number
> of open JIRA.

>From the point of view of open-source community (set aside corporate culture
etc.), there is no difference between "unassigned" and "in progress" issue,
as this basically means that the fix is still not available.

And if anyone _really_ interested in fixing a problem, then reading comments
and interacting with others interested in the same problem is *good*.
It facilitates better patch and design review, and overall leads to a better
software quality.

However, several engineers working on the same problem is perceived as
an inefficiency in corporate setting, and thus is stated as a problem.

Thus, the second problem is also induced by _sponsoring corporations_.

In short, both Harmony contributors and committers (with "Harmony hat on") have
*none* of the stated above problems.
It is managers of sponsoring corporations that need improvement in JIRA
searching capabilities.

I am not suggesting that Harmony should ignore wishes of the managers
of sponsoring corporations, but I think that the problem could be solved
much better if the problem and its justification is stated clearly,
without alluding to contributor problems which do not really exist.


But then, with current JIRA configurations, some problems do exist,
which could be addressed tweaking JIRA configuration, but now requires
mail communication. This is something that I encountered in *my practice*:

* When submitting a patch for an issue filed by someone else, the committer
attention will not be attracted automatically, because I can't set 'patch
available' status. The workaround for this is to create subtask for the
fixed issue, and attach patch to that subtask, with 'patch available' set.
IMHO, this workaround is good enough.

* When searching for issues related to particular component, I can easily
miss some of them, because '[component]' notation is not universally used
(now and then someone forgets to add component), and since only committers
and submitters are allowed to edit jira summary and categories, cleaning
up issues requires mail communications.

IMHO, None of this is critical, and may be left as is.

> How about the following structure:
> 1) Contributor assignee field for everybody (if a committer working on
> patch preparation he/she should use this field). Also, for example, if it's
> non-null then the status of unresolved JIRA is "In progress" automatically.
> 2) Committer assignee field for committers

These are not really needed neither to committers, nor to contributors.
It will not do any harm though, and definitely will be useful
for sponsoring corporations.

So, +0

> 3) Everybody could set "Patch available" tag (another option is: JIRA
> contributor assignee, JIRA author or committers coud set this tag)

This will make submitting patches easier for contributors.
+1

Re: [general] JIRA issue search problem

[Pavel Pervov <pm...@gmail.com>]

+1.
This is almost perfect for fast queries.

The only addition to this would be JIRA category instead of '[some
component][some module]' tags.

Regards
-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division

Re: [general] JIRA issue search problem

[Vladimir Beliaev <vl...@gmail.com>]

+1
Hope it is technically possible.

Thanks
VB

Oleg Khaschansky wrote:
>> 1) Contributor assignee field for everybody (if a committer working on 
>> patch
>> preparation he/she should use this field). Also, for example, if it's
>> non-null then the status of unresolved JIRA is "In progress" 
>> automatically.
>> 2) Committer assignee field for committers
>> 3) Everybody could set "Patch available" tag (another option is: JIRA
>> contributor assignee, JIRA author or committers coud set this tag)
> 
> +1.
> The suggested improvements could be extremely useful for non-committers.
> 
> On 12/15/06, Mikhail Markov <mi...@gmail.com> wrote:
>> +1 for this solution. How about the following structure:
>> 1) Contributor assignee field for everybody (if a committer working on 
>> patch
>> preparation he/she should use this field). Also, for example, if it's
>> non-null then the status of unresolved JIRA is "In progress" 
>> automatically.
>> 2) Committer assignee field for committers
>> 3) Everybody could set "Patch available" tag (another option is: JIRA
>> contributor assignee, JIRA author or committers coud set this tag)
>>
>> Regards,
>> Mikhail
>>
>> On 12/15/06, Alexey Petrenko <al...@gmail.com> wrote:
>> >
>> > 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
>> > > Alexey Petrenko wrote:
>> > > > I've just realized that I forgot about my another favorit 
>> search: "My
>> > > > unresolved".
>> > > > So I believe that contributors will be happy to have possibility to
>> > > > assign issues to themselves. But as I said using Assignee field for
>> > > > this is a bad idea...
>> > > >
>> > > > Is that possible to create another field, lets say "Contributor
>> > > > assignee" with the possibility to assign every registered JIRA 
>> user to
>> > > > this field? Geir?
>> > > >
>> > > > Is this makes sense? Thoughts?
>> > > What is it used for?  A non-committer asignee?
>> > When contributor starts working on the issue he can assing an issue to
>> > himself in special assignee field. In this case he can filter all the
>> > issues he working on and others can filter all assigned issues.
>> >
>> > This should help non-committers in searching for free to fix issues 
>> a lot.
>> >
>> > SY, Alexey
>> >
>> > > > 2006/12/14, Alexei Zakharov <al...@gmail.com>:
>> > > >> I've just imagined a bad guy who don't want particular JIRA to be
>> > > >> fixed (by some reason). He assigns this JIRA and logs off 
>> forever. So
>> > > >> the JIRA is in assigned state and no one else tries to work on it.
>> > > >> What should we do in this case?
>> > > > We will have the same result now if some bad guy will write a 
>> comment
>> > > > that he works on the issue :)
>> > > >
>> > > > SY, Alexey
>> > > >
>> > > >> 2006/12/14, Alexey Petrenko <al...@gmail.com>:
>> > > >> > Guys,
>> > > >> >
>> > > >> > this thread is created as a result of  "[general] Wise JIRA
>> > > >> processing" thread.
>> > > >> > Few people concerned that it is difficult to find a free JIRA 
>> issue
>> > to
>> > > >> > work on. And I agree with this concern.
>> > > >> >
>> > > >> > Committer can assign the issue to himself when he is starting to
>> > > >> > investigate the issue. And others can filter for non-assigned
>> > issues.
>> > > >> > But non-committer can not set any flag for the issue to let 
>> other
>> > > >> > people to filter.
>> > > >> >
>> > > >> > I do not think that granting possibility to non-committers to
>> > assign
>> > > >> > issues is a good idea since it will remove the possibility for
>> > > >> > committers to filter non-assigned bugs to commit.
>> > > >> >
>> > > >> > I suggest to let non-committers to set and unset "in progress"
>> > > >> > property. In this case non-committer will add comment to the 
>> issue
>> > > >> > that he started investigation and will set the "in progress"
>> > property.
>> > > >> > And others will can filter issues by this field.
>> > > >> >
>> > > >> > Thoughts?
>> > > >> >
>> > > >> > Geir, is this possible at all? :)
>> > > >> >
>> > > >> > SY, Alexey
>> > > >> >
>> > > >>
>> > > >>
>> > > >> --
>> > > >> Alexei Zakharov,
>> > > >> Intel ESSD
>> > > >>
>> > >
>> > >
>> >
>>
>>
> 

Re: [general] JIRA issue search problem

[Oleg Khaschansky <ol...@gmail.com>]

> 1) Contributor assignee field for everybody (if a committer working on patch
> preparation he/she should use this field). Also, for example, if it's
> non-null then the status of unresolved JIRA is "In progress" automatically.
> 2) Committer assignee field for committers
> 3) Everybody could set "Patch available" tag (another option is: JIRA
> contributor assignee, JIRA author or committers coud set this tag)

+1.
The suggested improvements could be extremely useful for non-committers.

On 12/15/06, Mikhail Markov <mi...@gmail.com> wrote:
> +1 for this solution. How about the following structure:
> 1) Contributor assignee field for everybody (if a committer working on patch
> preparation he/she should use this field). Also, for example, if it's
> non-null then the status of unresolved JIRA is "In progress" automatically.
> 2) Committer assignee field for committers
> 3) Everybody could set "Patch available" tag (another option is: JIRA
> contributor assignee, JIRA author or committers coud set this tag)
>
> Regards,
> Mikhail
>
> On 12/15/06, Alexey Petrenko <al...@gmail.com> wrote:
> >
> > 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
> > > Alexey Petrenko wrote:
> > > > I've just realized that I forgot about my another favorit search: "My
> > > > unresolved".
> > > > So I believe that contributors will be happy to have possibility to
> > > > assign issues to themselves. But as I said using Assignee field for
> > > > this is a bad idea...
> > > >
> > > > Is that possible to create another field, lets say "Contributor
> > > > assignee" with the possibility to assign every registered JIRA user to
> > > > this field? Geir?
> > > >
> > > > Is this makes sense? Thoughts?
> > > What is it used for?  A non-committer asignee?
> > When contributor starts working on the issue he can assing an issue to
> > himself in special assignee field. In this case he can filter all the
> > issues he working on and others can filter all assigned issues.
> >
> > This should help non-committers in searching for free to fix issues a lot.
> >
> > SY, Alexey
> >
> > > > 2006/12/14, Alexei Zakharov <al...@gmail.com>:
> > > >> I've just imagined a bad guy who don't want particular JIRA to be
> > > >> fixed (by some reason). He assigns this JIRA and logs off forever. So
> > > >> the JIRA is in assigned state and no one else tries to work on it.
> > > >> What should we do in this case?
> > > > We will have the same result now if some bad guy will write a comment
> > > > that he works on the issue :)
> > > >
> > > > SY, Alexey
> > > >
> > > >> 2006/12/14, Alexey Petrenko <al...@gmail.com>:
> > > >> > Guys,
> > > >> >
> > > >> > this thread is created as a result of  "[general] Wise JIRA
> > > >> processing" thread.
> > > >> > Few people concerned that it is difficult to find a free JIRA issue
> > to
> > > >> > work on. And I agree with this concern.
> > > >> >
> > > >> > Committer can assign the issue to himself when he is starting to
> > > >> > investigate the issue. And others can filter for non-assigned
> > issues.
> > > >> > But non-committer can not set any flag for the issue to let other
> > > >> > people to filter.
> > > >> >
> > > >> > I do not think that granting possibility to non-committers to
> > assign
> > > >> > issues is a good idea since it will remove the possibility for
> > > >> > committers to filter non-assigned bugs to commit.
> > > >> >
> > > >> > I suggest to let non-committers to set and unset "in progress"
> > > >> > property. In this case non-committer will add comment to the issue
> > > >> > that he started investigation and will set the "in progress"
> > property.
> > > >> > And others will can filter issues by this field.
> > > >> >
> > > >> > Thoughts?
> > > >> >
> > > >> > Geir, is this possible at all? :)
> > > >> >
> > > >> > SY, Alexey
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> Alexei Zakharov,
> > > >> Intel ESSD
> > > >>
> > >
> > >
> >
>
>

Re: [general] JIRA issue search problem

[Mikhail Markov <mi...@gmail.com>]

+1 for this solution. How about the following structure:
1) Contributor assignee field for everybody (if a committer working on patch
preparation he/she should use this field). Also, for example, if it's
non-null then the status of unresolved JIRA is "In progress" automatically.
2) Committer assignee field for committers
3) Everybody could set "Patch available" tag (another option is: JIRA
contributor assignee, JIRA author or committers coud set this tag)

Regards,
Mikhail

On 12/15/06, Alexey Petrenko <al...@gmail.com> wrote:
>
> 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
> > Alexey Petrenko wrote:
> > > I've just realized that I forgot about my another favorit search: "My
> > > unresolved".
> > > So I believe that contributors will be happy to have possibility to
> > > assign issues to themselves. But as I said using Assignee field for
> > > this is a bad idea...
> > >
> > > Is that possible to create another field, lets say "Contributor
> > > assignee" with the possibility to assign every registered JIRA user to
> > > this field? Geir?
> > >
> > > Is this makes sense? Thoughts?
> > What is it used for?  A non-committer asignee?
> When contributor starts working on the issue he can assing an issue to
> himself in special assignee field. In this case he can filter all the
> issues he working on and others can filter all assigned issues.
>
> This should help non-committers in searching for free to fix issues a lot.
>
> SY, Alexey
>
> > > 2006/12/14, Alexei Zakharov <al...@gmail.com>:
> > >> I've just imagined a bad guy who don't want particular JIRA to be
> > >> fixed (by some reason). He assigns this JIRA and logs off forever. So
> > >> the JIRA is in assigned state and no one else tries to work on it.
> > >> What should we do in this case?
> > > We will have the same result now if some bad guy will write a comment
> > > that he works on the issue :)
> > >
> > > SY, Alexey
> > >
> > >> 2006/12/14, Alexey Petrenko <al...@gmail.com>:
> > >> > Guys,
> > >> >
> > >> > this thread is created as a result of  "[general] Wise JIRA
> > >> processing" thread.
> > >> > Few people concerned that it is difficult to find a free JIRA issue
> to
> > >> > work on. And I agree with this concern.
> > >> >
> > >> > Committer can assign the issue to himself when he is starting to
> > >> > investigate the issue. And others can filter for non-assigned
> issues.
> > >> > But non-committer can not set any flag for the issue to let other
> > >> > people to filter.
> > >> >
> > >> > I do not think that granting possibility to non-committers to
> assign
> > >> > issues is a good idea since it will remove the possibility for
> > >> > committers to filter non-assigned bugs to commit.
> > >> >
> > >> > I suggest to let non-committers to set and unset "in progress"
> > >> > property. In this case non-committer will add comment to the issue
> > >> > that he started investigation and will set the "in progress"
> property.
> > >> > And others will can filter issues by this field.
> > >> >
> > >> > Thoughts?
> > >> >
> > >> > Geir, is this possible at all? :)
> > >> >
> > >> > SY, Alexey
> > >> >
> > >>
> > >>
> > >> --
> > >> Alexei Zakharov,
> > >> Intel ESSD
> > >>
> >
> >
>

Re: [general] JIRA issue search problem

[Alexey Petrenko <al...@gmail.com>]

Geir?

2006/12/19, Alexey Petrenko <al...@gmail.com>:
> Geir,
>
> is this possible to implement or not?
>
> SY, Alexey
>
> 2006/12/15, Alexey Petrenko <al...@gmail.com>:
> > 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
> > > Alexey Petrenko wrote:
> > > > I've just realized that I forgot about my another favorit search: "My
> > > > unresolved".
> > > > So I believe that contributors will be happy to have possibility to
> > > > assign issues to themselves. But as I said using Assignee field for
> > > > this is a bad idea...
> > > >
> > > > Is that possible to create another field, lets say "Contributor
> > > > assignee" with the possibility to assign every registered JIRA user to
> > > > this field? Geir?
> > > >
> > > > Is this makes sense? Thoughts?
> > > What is it used for?  A non-committer asignee?
> > When contributor starts working on the issue he can assing an issue to
> > himself in special assignee field. In this case he can filter all the
> > issues he working on and others can filter all assigned issues.
> >
> > This should help non-committers in searching for free to fix issues a lot.
> >
> > SY, Alexey
> >
> > > > 2006/12/14, Alexei Zakharov <al...@gmail.com>:
> > > >> I've just imagined a bad guy who don't want particular JIRA to be
> > > >> fixed (by some reason). He assigns this JIRA and logs off forever. So
> > > >> the JIRA is in assigned state and no one else tries to work on it.
> > > >> What should we do in this case?
> > > > We will have the same result now if some bad guy will write a comment
> > > > that he works on the issue :)
> > > >
> > > > SY, Alexey
> > > >
> > > >> 2006/12/14, Alexey Petrenko <al...@gmail.com>:
> > > >> > Guys,
> > > >> >
> > > >> > this thread is created as a result of  "[general] Wise JIRA
> > > >> processing" thread.
> > > >> > Few people concerned that it is difficult to find a free JIRA issue to
> > > >> > work on. And I agree with this concern.
> > > >> >
> > > >> > Committer can assign the issue to himself when he is starting to
> > > >> > investigate the issue. And others can filter for non-assigned issues.
> > > >> > But non-committer can not set any flag for the issue to let other
> > > >> > people to filter.
> > > >> >
> > > >> > I do not think that granting possibility to non-committers to assign
> > > >> > issues is a good idea since it will remove the possibility for
> > > >> > committers to filter non-assigned bugs to commit.
> > > >> >
> > > >> > I suggest to let non-committers to set and unset "in progress"
> > > >> > property. In this case non-committer will add comment to the issue
> > > >> > that he started investigation and will set the "in progress" property.
> > > >> > And others will can filter issues by this field.
> > > >> >
> > > >> > Thoughts?
> > > >> >
> > > >> > Geir, is this possible at all? :)
> > > >> >
> > > >> > SY, Alexey
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> Alexei Zakharov,
> > > >> Intel ESSD
> > > >>
> > >
> > >
> >
>

Re: [general] JIRA issue search problem

[Alexey Petrenko <al...@gmail.com>]

Geir?

2006/12/19, Alexey Petrenko <al...@gmail.com>:
> Geir,
>
> is this possible to implement or not?
>
> SY, Alexey
>
> 2006/12/15, Alexey Petrenko <al...@gmail.com>:
> > 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
> > > Alexey Petrenko wrote:
> > > > I've just realized that I forgot about my another favorit search: "My
> > > > unresolved".
> > > > So I believe that contributors will be happy to have possibility to
> > > > assign issues to themselves. But as I said using Assignee field for
> > > > this is a bad idea...
> > > >
> > > > Is that possible to create another field, lets say "Contributor
> > > > assignee" with the possibility to assign every registered JIRA user to
> > > > this field? Geir?
> > > >
> > > > Is this makes sense? Thoughts?
> > > What is it used for?  A non-committer asignee?
> > When contributor starts working on the issue he can assing an issue to
> > himself in special assignee field. In this case he can filter all the
> > issues he working on and others can filter all assigned issues.
> >
> > This should help non-committers in searching for free to fix issues a lot.
> >
> > SY, Alexey
> >
> > > > 2006/12/14, Alexei Zakharov <al...@gmail.com>:
> > > >> I've just imagined a bad guy who don't want particular JIRA to be
> > > >> fixed (by some reason). He assigns this JIRA and logs off forever. So
> > > >> the JIRA is in assigned state and no one else tries to work on it.
> > > >> What should we do in this case?
> > > > We will have the same result now if some bad guy will write a comment
> > > > that he works on the issue :)
> > > >
> > > > SY, Alexey
> > > >
> > > >> 2006/12/14, Alexey Petrenko <al...@gmail.com>:
> > > >> > Guys,
> > > >> >
> > > >> > this thread is created as a result of  "[general] Wise JIRA
> > > >> processing" thread.
> > > >> > Few people concerned that it is difficult to find a free JIRA issue to
> > > >> > work on. And I agree with this concern.
> > > >> >
> > > >> > Committer can assign the issue to himself when he is starting to
> > > >> > investigate the issue. And others can filter for non-assigned issues.
> > > >> > But non-committer can not set any flag for the issue to let other
> > > >> > people to filter.
> > > >> >
> > > >> > I do not think that granting possibility to non-committers to assign
> > > >> > issues is a good idea since it will remove the possibility for
> > > >> > committers to filter non-assigned bugs to commit.
> > > >> >
> > > >> > I suggest to let non-committers to set and unset "in progress"
> > > >> > property. In this case non-committer will add comment to the issue
> > > >> > that he started investigation and will set the "in progress" property.
> > > >> > And others will can filter issues by this field.
> > > >> >
> > > >> > Thoughts?
> > > >> >
> > > >> > Geir, is this possible at all? :)
> > > >> >
> > > >> > SY, Alexey
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> Alexei Zakharov,
> > > >> Intel ESSD
> > > >>
> > >
> > >
> >
>

Re: [general] JIRA issue search problem

[Alexey Petrenko <al...@gmail.com>]

Geir,

is this possible to implement or not?

SY, Alexey

2006/12/15, Alexey Petrenko <al...@gmail.com>:
> 2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
> > Alexey Petrenko wrote:
> > > I've just realized that I forgot about my another favorit search: "My
> > > unresolved".
> > > So I believe that contributors will be happy to have possibility to
> > > assign issues to themselves. But as I said using Assignee field for
> > > this is a bad idea...
> > >
> > > Is that possible to create another field, lets say "Contributor
> > > assignee" with the possibility to assign every registered JIRA user to
> > > this field? Geir?
> > >
> > > Is this makes sense? Thoughts?
> > What is it used for?  A non-committer asignee?
> When contributor starts working on the issue he can assing an issue to
> himself in special assignee field. In this case he can filter all the
> issues he working on and others can filter all assigned issues.
>
> This should help non-committers in searching for free to fix issues a lot.
>
> SY, Alexey
>
> > > 2006/12/14, Alexei Zakharov <al...@gmail.com>:
> > >> I've just imagined a bad guy who don't want particular JIRA to be
> > >> fixed (by some reason). He assigns this JIRA and logs off forever. So
> > >> the JIRA is in assigned state and no one else tries to work on it.
> > >> What should we do in this case?
> > > We will have the same result now if some bad guy will write a comment
> > > that he works on the issue :)
> > >
> > > SY, Alexey
> > >
> > >> 2006/12/14, Alexey Petrenko <al...@gmail.com>:
> > >> > Guys,
> > >> >
> > >> > this thread is created as a result of  "[general] Wise JIRA
> > >> processing" thread.
> > >> > Few people concerned that it is difficult to find a free JIRA issue to
> > >> > work on. And I agree with this concern.
> > >> >
> > >> > Committer can assign the issue to himself when he is starting to
> > >> > investigate the issue. And others can filter for non-assigned issues.
> > >> > But non-committer can not set any flag for the issue to let other
> > >> > people to filter.
> > >> >
> > >> > I do not think that granting possibility to non-committers to assign
> > >> > issues is a good idea since it will remove the possibility for
> > >> > committers to filter non-assigned bugs to commit.
> > >> >
> > >> > I suggest to let non-committers to set and unset "in progress"
> > >> > property. In this case non-committer will add comment to the issue
> > >> > that he started investigation and will set the "in progress" property.
> > >> > And others will can filter issues by this field.
> > >> >
> > >> > Thoughts?
> > >> >
> > >> > Geir, is this possible at all? :)
> > >> >
> > >> > SY, Alexey
> > >> >
> > >>
> > >>
> > >> --
> > >> Alexei Zakharov,
> > >> Intel ESSD
> > >>
> >
> >
>

Re: [general] JIRA issue search problem

[Alexey Petrenko <al...@gmail.com>]

2006/12/14, Geir Magnusson Jr. <ge...@pobox.com>:
> Alexey Petrenko wrote:
> > I've just realized that I forgot about my another favorit search: "My
> > unresolved".
> > So I believe that contributors will be happy to have possibility to
> > assign issues to themselves. But as I said using Assignee field for
> > this is a bad idea...
> >
> > Is that possible to create another field, lets say "Contributor
> > assignee" with the possibility to assign every registered JIRA user to
> > this field? Geir?
> >
> > Is this makes sense? Thoughts?
> What is it used for?  A non-committer asignee?
When contributor starts working on the issue he can assing an issue to
himself in special assignee field. In this case he can filter all the
issues he working on and others can filter all assigned issues.

This should help non-committers in searching for free to fix issues a lot.

SY, Alexey

> > 2006/12/14, Alexei Zakharov <al...@gmail.com>:
> >> I've just imagined a bad guy who don't want particular JIRA to be
> >> fixed (by some reason). He assigns this JIRA and logs off forever. So
> >> the JIRA is in assigned state and no one else tries to work on it.
> >> What should we do in this case?
> > We will have the same result now if some bad guy will write a comment
> > that he works on the issue :)
> >
> > SY, Alexey
> >
> >> 2006/12/14, Alexey Petrenko <al...@gmail.com>:
> >> > Guys,
> >> >
> >> > this thread is created as a result of  "[general] Wise JIRA
> >> processing" thread.
> >> > Few people concerned that it is difficult to find a free JIRA issue to
> >> > work on. And I agree with this concern.
> >> >
> >> > Committer can assign the issue to himself when he is starting to
> >> > investigate the issue. And others can filter for non-assigned issues.
> >> > But non-committer can not set any flag for the issue to let other
> >> > people to filter.
> >> >
> >> > I do not think that granting possibility to non-committers to assign
> >> > issues is a good idea since it will remove the possibility for
> >> > committers to filter non-assigned bugs to commit.
> >> >
> >> > I suggest to let non-committers to set and unset "in progress"
> >> > property. In this case non-committer will add comment to the issue
> >> > that he started investigation and will set the "in progress" property.
> >> > And others will can filter issues by this field.
> >> >
> >> > Thoughts?
> >> >
> >> > Geir, is this possible at all? :)
> >> >
> >> > SY, Alexey
> >> >
> >>
> >>
> >> --
> >> Alexei Zakharov,
> >> Intel ESSD
> >>
>
>

Re: [general] JIRA issue search problem

["Geir Magnusson Jr." <ge...@pobox.com>]

Alexey Petrenko wrote:
> I've just realized that I forgot about my another favorit search: "My
> unresolved".
> So I believe that contributors will be happy to have possibility to
> assign issues to themselves. But as I said using Assignee field for
> this is a bad idea...
> 
> Is that possible to create another field, lets say "Contributor
> assignee" with the possibility to assign every registered JIRA user to
> this field? Geir?
> 
> Is this makes sense? Thoughts?

What is it used for?  A non-committer asignee?

> 
> SY, Alexey
> 
> 2006/12/14, Alexei Zakharov <al...@gmail.com>:
>> I've just imagined a bad guy who don't want particular JIRA to be
>> fixed (by some reason). He assigns this JIRA and logs off forever. So
>> the JIRA is in assigned state and no one else tries to work on it.
>> What should we do in this case?
> We will have the same result now if some bad guy will write a comment
> that he works on the issue :)
> 
> SY, Alexey
> 
>> 2006/12/14, Alexey Petrenko <al...@gmail.com>:
>> > Guys,
>> >
>> > this thread is created as a result of  "[general] Wise JIRA 
>> processing" thread.
>> > Few people concerned that it is difficult to find a free JIRA issue to
>> > work on. And I agree with this concern.
>> >
>> > Committer can assign the issue to himself when he is starting to
>> > investigate the issue. And others can filter for non-assigned issues.
>> > But non-committer can not set any flag for the issue to let other
>> > people to filter.
>> >
>> > I do not think that granting possibility to non-committers to assign
>> > issues is a good idea since it will remove the possibility for
>> > committers to filter non-assigned bugs to commit.
>> >
>> > I suggest to let non-committers to set and unset "in progress"
>> > property. In this case non-committer will add comment to the issue
>> > that he started investigation and will set the "in progress" property.
>> > And others will can filter issues by this field.
>> >
>> > Thoughts?
>> >
>> > Geir, is this possible at all? :)
>> >
>> > SY, Alexey
>> >
>>
>>
>> -- 
>> Alexei Zakharov,
>> Intel ESSD
>>

Re: [general] JIRA issue search problem

[Alexey Petrenko <al...@gmail.com>]

I've just realized that I forgot about my another favorit search: "My
unresolved".
So I believe that contributors will be happy to have possibility to
assign issues to themselves. But as I said using Assignee field for
this is a bad idea...

Is that possible to create another field, lets say "Contributor
assignee" with the possibility to assign every registered JIRA user to
this field? Geir?

Is this makes sense? Thoughts?

SY, Alexey

2006/12/14, Alexei Zakharov <al...@gmail.com>:
> I've just imagined a bad guy who don't want particular JIRA to be
> fixed (by some reason). He assigns this JIRA and logs off forever. So
> the JIRA is in assigned state and no one else tries to work on it.
> What should we do in this case?
We will have the same result now if some bad guy will write a comment
that he works on the issue :)

SY, Alexey

> 2006/12/14, Alexey Petrenko <al...@gmail.com>:
> > Guys,
> >
> > this thread is created as a result of  "[general] Wise JIRA processing" thread.
> > Few people concerned that it is difficult to find a free JIRA issue to
> > work on. And I agree with this concern.
> >
> > Committer can assign the issue to himself when he is starting to
> > investigate the issue. And others can filter for non-assigned issues.
> > But non-committer can not set any flag for the issue to let other
> > people to filter.
> >
> > I do not think that granting possibility to non-committers to assign
> > issues is a good idea since it will remove the possibility for
> > committers to filter non-assigned bugs to commit.
> >
> > I suggest to let non-committers to set and unset "in progress"
> > property. In this case non-committer will add comment to the issue
> > that he started investigation and will set the "in progress" property.
> > And others will can filter issues by this field.
> >
> > Thoughts?
> >
> > Geir, is this possible at all? :)
> >
> > SY, Alexey
> >
>
>
> --
> Alexei Zakharov,
> Intel ESSD
>

Re: [general] JIRA issue search problem

[Alexei Zakharov <al...@gmail.com>]

I've just imagined a bad guy who don't want particular JIRA to be
fixed (by some reason). He assigns this JIRA and logs off forever. So
the JIRA is in assigned state and no one else tries to work on it.
What should we do in this case?

Regards,

2006/12/14, Alexey Petrenko <al...@gmail.com>:
> Guys,
>
> this thread is created as a result of  "[general] Wise JIRA processing" thread.
> Few people concerned that it is difficult to find a free JIRA issue to
> work on. And I agree with this concern.
>
> Committer can assign the issue to himself when he is starting to
> investigate the issue. And others can filter for non-assigned issues.
> But non-committer can not set any flag for the issue to let other
> people to filter.
>
> I do not think that granting possibility to non-committers to assign
> issues is a good idea since it will remove the possibility for
> committers to filter non-assigned bugs to commit.
>
> I suggest to let non-committers to set and unset "in progress"
> property. In this case non-committer will add comment to the issue
> that he started investigation and will set the "in progress" property.
> And others will can filter issues by this field.
>
> Thoughts?
>
> Geir, is this possible at all? :)
>
> SY, Alexey
>


-- 
Alexei Zakharov,
Intel ESSD