@eddieajau had some proposal here #257

+1 I think it's a starting point.

Again we are facing here the limitation of GitHub. How do we map categories? As the labels as Andrew suggested or we do not need to map them at all?

I agree with Andrew's gist here
https://gist.github.com/eddieajau/fdcdd5e607adce0a3f6d
It's better and more clear.
If we don't map, it would be hard when using Github alone.
But if we do map, labels sometimes can be annoying, that is to say, an issue might have lots of labels, will be hard for users to read on GitHub.

@allenzhao during his GSoC project should provide the Categories. He will be ready to code in one week, so we need to establish the interim guidelines for how labels can be used in Github to supplement our categorization of issues.

Here are some questions that we should discuss:

1. What categories do we need?
2. How to map them on GitHub?
3. Who should have rights to manage Categories?
4. ...

The Categories are the vital part of a new tracker so I call up to all JBS members - please share your ideas.

Thank you!

@betweenbrain @zero-24 @roland-d

Can anyone repost andrews gist? I can't seem to view it?

I think categories needs to be dynamic because if Joomla wants to focus on something in particular then we want to be able to add new categories (e.g. if we want have a postgres cleanup we can add a postgres category and encourage people to test in there). I think probably only the Leadership should have permissions to manage the categories themselves though and then obviously JBS people to add a category label to an issue

I think we have a good set of categories on the tracker though at least to start with. components, code quality, libraries seems like the main 3.

I think the only way to map them is via more labels

@wilsonge Sorry but I didn't save that gist, maybe we need @eddieajau to repost it;)
I agree with you, but I think we need to make it more clear for people who are using GitHub, otherwise tons of labels may make them feel lost, at least I do sometimes.
I remembered Andrew provided a way, not only to map category with label, but also map other status of an issue with label. But right now I'm not sure about how it would work. ;( I should've kept that gist.

Thanks @b2z

Here my ideas

What categories do we need?

They should be dynamic as @wilsonge noted but as start here a quick list:

• ACL
• Administation
• Front End
• Automated Test
• Code Quality
• Authentication & Login
• Installation & Updating
• Languages & Strings
• Multilanguage
• Plugins
• Modules
• Components
• Templates
• Layouts
• Libraries (internal libraries /cms /joomla /legacy)
• External Libraries (all external libraries e.g. framework, PHPass, phpmailer,...)
• User Interface
• Search Engine Friendly
• Database / SQL Files (installation and update sql files)
• None (default)

Who should have rights to manage Categories?

Add and remove it globally --> only commiters / github maintainers / leadership members
Add it to a itm --> JBS Members and (if possible) on create the creator of the new issue

How to map them on GitHub?

As label (as we have it for "Needs JC" or "Have JC" ) and only one (like the current behavior on JC). see below multiple are cool.

@note i can't and have not read the gist @eddieajau

Could the categories only be managed in JIssues and not mapped to GitHub at all?
I don't think that all the data from JIssues needs to be available in GitHub as well.
If we add everything in GitHub, it becomes unmanageable fast and in the end will be contraproductive.

Actually I think @Bakual makes a very good point there. I don't think that's essential information for github

I want to hear issue starter @brianteeman :)

And one more question - issue can be assigned to multiple categories?

The list by @zero-24 sounds good

@bakual is right they dont "need" to be mapped to github but it would be "nice" if they were (as tags)

For the initial implementation, I'd keep the categories local to the application. We still need to define a workflow where a user who doesn't have the rights on GitHub would be able to change something like labels via the bot accounts.

Assigning something to multiple categories; I don't see why not.

We still need to define a workflow where a user who doesn't have the rights on GitHub would be able to change something like labels via the bot accounts.

Possible via a group with selected JBS members or all JBS members?

And one more question - issue can be assigned to multiple categories?

hmm i think yes. e.g.

• Components and Languages & Strings (if it add / change / remove a langauge string and is in a component, ...)
• Modules and Code Quality (code quality in a module,...)

....

Thank you all. Now we have everything we need to do the coding!

So please let me make a small conclusion here:
1. We won't map the categories into GitHub, we will just do it locally,
2. Category choosing, editing,etc should be done under ACL, i.e. a selected group
3. An issue can be assigned to multiple categories
4. After implementation, categories should be able to filter by filter tools too.
@b2z @zero-24 @wilsonge @brianteeman @mbabker @Bakual Anything I'm missing?

Sounds good to me :)

@allenzhao

5) Categories should be dynamic add, remove, change by maintainers

1. Category choosing, editing,etc should be done under ACL, i.e. a selected group

I think the one who opens an issue should be allowed to choose a category and maybe (not necessary) also edit later on in his own issue. JBS group should be able to edit the category on each issue.

I think the filtering is probably the most important thing :)

Adding an Issue

Editing an Issue

Displaying the issue

These are the ugly UIs of category
Please give some advice! Thanks so much;)

And for the displaying badge - Is it necessary for admins to edit the color of the badge or shall we just set them to some default values?

I am currently playing with implementing labels and I am facing similar UI disasters

I think for the item view we should go with something like we already have for labels.
I would separate the category badges from the others (build, priority, etc) making them a separate group.

For the edit/add views I think we should look for something "collapsible". Think about having hundreds of categories...

What GitHub has for selecting labels, milestones etc. in the edit and list views looks pretty cool. I think it's a bootstrap modal window with some logic for searching etc. - You have been proven to have decent JavaScript knowledge, maybe you can come up with something?

The GitHub thingy looks like this:

Alternatively, this here seems to have the options we might require: http://silviomoreto.github.io/bootstrap-select/

How does that sound?

Oh and YES - I think we should provide colors :)

I found this: http://davidstutz.github.io/bootstrap-multiselect/
I think it's better ;)
And for the color thing, needs some discussion on details :)

I guess I need some idea here,
Do we need to allow to filter with multiple categories chosen?
If yes, do we need them to be 'OR' relationship or ‘AND' relationship?

I don't think so. Filtering by one category at a time should be enough.

Filtering by one category at a time should be enough.

Now it's on the live site;) Thanks to @mbabker for deploy so fast after the merge;)
And let me mention everyone here @zero-24 @wilsonge @brianteeman @Bakual
Admins should be able to add categories now through here:

And also, you can manage by adding, deleting and editing in here:

Notes
1. The alias is for filtering, so name it like project alias: action-pending , etc;
2. The color thing, you don't need to add the # before the value, 6 digit hex color will do;)

And if there's any bug, report I will try to fix it;) Hope there isn't any after me and @b2z testing again and again;)

Thanks for all the help along the way of implementing this and I'm really thrilled to see all this working;)

Now someone needs to think up colours for the list mentioned here

Excellent work @allenzhao !!
Thank you very much for your contribution!

Awesome work man! Thankyou so much!

Now someone needs to think up colours for the list mentioned here

I thought that we had colors covered already?

Closing this

Thanks @allenzhao good work!

I thought that we had colors covered already?

Where is it? Since we are now officially on the new tracker it would be nice to add categories. We have a list and we need only colors now ;) And we should keep in mind what is proposed in #432

@Bakual @brianteeman @zero-24 @vdespa @roland-d @wilsonge

I thought that we had colors covered already?

Where is it?

Still not sure what's missing, I believe that we have the "feature implemented".

If you mean "setting up the categories" for the project as in this list, and assigning the "correct" color to every category, this would be the job of a user belonging to a group with "manage" permissions.

Do you think we should do anything here code wise? maybe creating some default categories when adding a new project, or "hard coding" the category list for the Joomla! projects we have in our install.sql file?

I am talking about setting up categories, yes ;)

Best regards,
Dmitry

----- Reply message -----
From: "Nikolai Plath" notifications@github.com
To: "joomla/jissues" jissues@noreply.github.com
Cc: "Dmitry Rekun" bzzjuka@gmail.com
Subject: [jissues] Categories (#317)
Date: Fri, Aug 22, 2014 19:54
I thought that we had colors covered already?

Where is it?

Still not sure what-s missing. We have the "feature implemented".

f you mean setting up the categories for the project as in the list, and assigning the "correct" color to every category, this would be the job of a user belonging to a group with "manage" permissions.

Do you think we should do anything here code wise? maybe creating some default categories when adding a new project, or "hard coding" the category list for the Joomla! projects we have in our install.sql file?

—
Reply to this email directly or view it on GitHub.

I am talking about setting up categories, yes ;)

Ah, OK ;)

I think maybe a color selector would be a nice addition (like the one they have on GitHub)