What do you mean it is not being used. I regularly set PR to easy

That is good to know you are setting PRs to Easy. When I checked before (not today but months ago) I found PRs set to Easy that were not Easy. I am aware that classifying a PR is a judgement call.

In any case, it will be useful to add the other two levels so we can separate the PRs a little more than just Easy or everything else.

@roland-d Irrespective of whether the easy tag is being used correctly it is still not the best way to achieve what you want to do.

In the issue tracker there is no batch tagging. It would be much easier for your use case to add a label in github

I just know we have this easy dropdown in the Jissues and figured that would be useful since it basically has the same use.

Why would the labels be a better fit?

1. Labels are displayed on the list view - the easy status does not
2. Labels appear on both the issue tracker and github - the easy status does not
3. Batch adding and removal is possible with labels

On 15 March 2015 at 10:28, RolandD notifications@github.com wrote:

I just know we have this easy dropdown in the Jissues and figured that
would be useful since it basically has the same use.

Why would the labels be a better fit?

—
Reply to this email directly or view it on GitHub
#631 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

1. Easy != PBF We always have a mix of people at a PBF and it is better (imho) to be able to show people a list if issues that we want to tackle at the PBF and that would include "easy" and "hard" issues

By using both EASY and PBF we can let people filter first on PBF and then
if they are not advanced they can filter again on EASY

I don't want to add a PBF label to the issues, just want to classify the issues as more than just easy. It is because of the mix that I want more than just the easy option. These issues we write on post-it notes and hang them on the wall for people to take, to get them off their seat and make the wall interactive and they can see the progress.

The gap between easy and hard is too large as far as I am concerned. There are quite a bunch of issues that fall in between. If we classify an issue as hard the majority of users will go for the easy ones. Medium ones they will try but they won't try hard issues.

The way issues are classified as Easy now is no different than classifying them as easy for a PBF event I think. If there is, then we have different set of how things are classified and then my point is moot to repurpose this.

So :) What is the final decision here?

Sorry for the late reply but real life got in the way. I am still wanting an option where I can classify the easy/medium/advanced status of an issue. Now we have to do this over and over again for every PBF, not very efficient. Yes, it is not an exact science but it is better than nothing.

I just dont see why it is over and over again and who is going to be doing
it. It should be part of the continual process. Plus if we were stricter
about removing useless issues and pull requests and feature requests for
things that are never going to happen and addressing the PR (10%) that are
waiting for a maintainer to make a decision on is it even something that we
need to do. Sorry but I really see this as a band aid to proper management
of the tracker

On 24 March 2015 at 17:14, RolandD notifications@github.com wrote:

Sorry for the late reply but real life got in the way. I am still wanting
an option where I can classify the easy/medium/advanced status of an issue.
Now we have to do this over and over again for every PBF, not very
efficient. Yes, it is not an exact science but it is better than nothing.

—
Reply to this email directly or view it on GitHub
#631 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

It should be part of the continual process.

Exactly the reason I am asking to have more options than just easy. So we can use it not only during the PBF but also in regular usage.

Plus if we were stricter about removing useless issues and pull requests and feature requests for things that are never going to happen and addressing the PR (10%) that are waiting for a maintainer to make a decision on is it even something that we need to do.

That is irrespective of the status. Even if this was cleaned up a 100% you would still have the issue of needing to say what kind of test it would be.

Sorry but I really see this as a band aid to proper management of the tracker

I think we are talking about two different things.

As I don't see this going anywhere, I will close my request and thank you all for your time.