For those reading this who were not at JWC this related to a reference to people "claiming" issues and then not doing anything. To avoid this the suggestion was that "claimed" issues not worked on would be unassigned and put back in the general pool.

Personally after reviewing far too many issues over the last year, especially those that have not been updated for a long time, the issue is NOT people assigning an issue to themselves and then not doing anything. Rather it is the comments that people have had a tendency of making which state the proposed solution could be better combined with another issue or be part of a complete rewrite of that area of the codebase. As a result the issue completely stalls as the proposer is not able/willing to be part of a complete rewrite and the person who suggested that just goes silent.

What we really need is a few people who are willing to be "moderators" of the trackers and can spot these issues before the cookie goes stale and take appropriate action.

@brianteeman thanks for the further clarification on the terminology, I should've explained more on that.

I agree with what you're saying too. A lot of issues that start as a simple 'fix this bug' end up in 'we should rewrite this from scratch', something beyond the time availability of a contributor who just wanted a bug fix. I'm not sure how to fix that issue though. Do you think implementing something oriented towards assignments like this will be a positive or negative influence on the other issue you're describing?

@drmmr763 I think what I am saying is the issue of "licking cookies" is not when people dont carry out their assigned tasks but make comments that kill the issue.

What you are talking about (imho) is to utilise the assign feature but to also have a release on inactivity function. I'm not sure how many issues that will really effect. Assigning issues isnt really something we have done for many years - it didnt really work for us

Ahh okay. Just to be clear, I'm not trying to solve the 'licked cookie problem' with this idea, at least not as it's most primary goal. I'm just reusing the terminology in an attempt at more playful play-on-words for assignment. Hopefully it'll help avoid the issue but that can be a nice side effect. So your assessment is pretty much correct. Also to be clear, I don't think it's a good idea for people to be able to assign things to others, but rather for you or I to have the ability to adopt an issue for ourselves, for a limited amount of time.

For reference on the JWC talk: http://www.youtube.com/watch?v=p8ft_H_wymU&feature=share&t=37m9s (starts around 37:00)

I like the idea of having something like an "auto assign" feature - You can only assign yourself to an issue, but not another person. That would be a good thing to overcome the issue of two people working on the same task.

And I like s ... Please implement....going to see that JWC talk later to see if I got you right ;)

Hey all:

So I have started working on this feature a bit. You can check out the code here https://github.com/drmmr763/jissues/tree/cookie-lick - I warn you I'm no where near asking anyone to test this yet though!

I had some questions about the implementation as I was working things out. I'm asking more for validation from you experts before I go further:

1. Toggle Function or Add / Remove functions?
   I'm asking here if I should have a single method called toggleLick which determines the "lick state" of an issue, and then when executed toggles that state. IE: if the item is unlicked, lick it, and if it's licked, see who licked it. If it's "me" then unlick it, if it's someone else then send an error. The 'add / remove' functions would be two separate functions. One for licking, one for unlicking. The javascript and some other issue-code would handle determining which one to use pending on the user and the lick state.

2. The 'licked' table
   There are a couple ways of handling the lick table:

   1. A new table which records the lick id, lick date, and lick user.
   2. Appending rows to the issues table (Add the lick user and lick date to the row)
   3. Utilizing the activities table in some way (Define an activity type of lick?)

If anyone cares enough to think about these thoughts and give me some general direction. I have some ideas of course but I'd much rather a more experienced person think about things like performance / queries etc..

Thanks

I am still did not completely understand this feature due to the fact that English is not my native language Can someone explain me more simply the idea? :)

The feature is really a 'claim this issue' button. For example if you are browsing the issue tracker and you find an issue you think you can solve. You would click "Claim" and then your name would show up on the item as the person who is working to solve the issue. In this way if someone else sees the same issue and sees that you are already working on it, you both won't be working to resolve it at the same time.

Another aspect of the feature would be automated un-claiming. If I claimed a feature a few weeks ago but I haven't had time to fix it yet, a cron job would check to see how long it's been, and if it's been too long it will un-claim the feature and other people will then be able to claim it for themselves.

These claim / unclaim actions could show up in the activity stream as well, and possibly use Github's 'assign' feature via API.

Does that make more sense now?

If the language barrier is an issue perhaps it would be best to do away with the analogy in favor of something more clear altogether. I'm certainly open to that.

Claim does seem a better explanation than lick in this instance

@drmmr763 thanks, now it is clear Probably I was confused due to the "lick cookie" expression

Back to you questions:

1. I'll vote for add / remove functions. One for licking, one for unlicking. These could be handeled by the issue model. I think there is no need in the LickModel.
   Something like this: $model->lick -> if it's the same user $model->unlickIssue, if it's another user $model->lickIssue.

2. I would stick to the separate lick table. Not sure regarding activity, because we will have the list of users showing who is currently licking an issue.

Why not just call it something like "I'm working on this" and make it a many to many relationship. You could rightly have 10 people working on solving a particular bug in some cases. Have the rules set so that it automatically expires if there is no activity from you within 7 days (because you are then obviously not working on it).

@b2z Thank you so much for the feedback. Your suggestions definitely feel right to me.

@eddieajau I appreciate the open minded suggestion on the idea altogether. I'm wondering if the use-case you're referring too (multiple contributors on a single issue) happens all that often. I definitely have seen many times on JoomlaCode where someone submits an almost-perfect patch, someone else completes it and posts the final working and accepted patch based on the original contributor's bug fixes. Your example and implementation idea certainly lends its self to that use case much better.

The only thing left out is Github's API and the 'assign this issue' state that they offer. Not saying we should be tied to that (I haven't even tried to tie my proof of concept to it yet) but my idea was a nod to that feature from the start.

I'm a little unsure of the best course of action. I like the idea of multiple people to say they're working on something of course - that's just how open source works most of the time. I'm beginning to think this conversation requires a bit more discussion before I try to keep writing something at this point.

I'm wondering if the use-case you're referring too (multiple contributors on a single issue) happens all that often

I don't really know. All I was trying to do was prevent the "licking" bit (nobody can lick the cookie, but everyone can say they want to take a bite).

The only thing left out is Github's API and the 'assign this issue' state that they offer.

I think ignore that completely for now.

I'm a little unsure of the best course of action.

It could be as simple detecting a hashtag in a comment #working-on-it or even the emoji. The UI could report:

Working on it

• eddieajau (3 months ago)
• drmmr763 (an hour ago)

As you can see, I'm obviously NOT working on it :)

Is this still valid?

It might still be a good feature idea but I've not worked on it :(