As more of the data structure gets built, this will all come together. If you want to help, we're going to try and get much of the data into the select_items table as practical. I see versions moving there soon, while categories and statuses being separate tables. I think we're at a point we can look at doing the canned queries concept too. There's enough data for us to start building out the features we need, but just know that everything isn't in place yet.

A thought I am currently playing with:
What if we use com_categories for that matter ?
It's a bit hard to explain, but since com_categories supports "sections", I think we can setup all of those fields as "categories".
So we can provide

• Projects - separate trackers for different projects
• Categories - as in "categories" may support multi level - not sure.
• Fields - single selects with different options. Examples: PHP version, browser, OS, etc.

All thus without writing any additional code, taking advantage of the "alias creation" and only using the #__categories table.

I would love to implement some sort of "custom fields" that can be arranged.

I believe that this will make the creation of personalized queries / views a lot easier.

I understand, that this issue is more about the work flow than the implementation, so sorry for being off-topic ;)

That could possibly work. Still a lot of ideas to spin my head around and think about, but if com_categories could do the job for us, why not use it?

After stripping com_categories down to the bare minimum, I think it will work for what we're looking for without all the extra stuff that comes from its use in the CMS structure. This probably needs a bit more work and testing to consider this part of the integration complete, but I think we're definitely on the right path now without having to roll our own code.

• BREAK *

As far as actual workflow goes, one thing I don't think we want to tie ourselves into is a system defined workflow. I tried it in my early days using Joomlacode as my project host, and it made managing my issue tracker a nightmare. Being flexible enough for the status to change to whatever we desire at a moment's notice should continue to be our way of business. We could add an additional "sub-status" to further clarify things if need be, or make our status field more descriptive.

In addition to the version fields, I'd like to add the commit SHA that the item was closed with also for quicker reference. We had that with Joomlacode when committed directly to the SVN there, but lost it switching here.

As for the canned queries, I think we're on to something in #1.

Nothing like returning to a year old item. Anyone with any comments here about it?

I see these options here:

• extend #__status table and add more statuses;
• create a table which will be related to #__status and redesign #__status table (#__status will have only basic ones and related table more specific ones).

I'd like some custom fields (selects, check boxes, etc.) that can be defined on a per project base.
And fore the canned queries - @vietvh still with us ?

Let's shoot out this v1 and see what people are missing... c'mon

That's why the v1.0 label (or any version label) isn't assigned here. Not
a v1 stopper ;-)

On Tuesday, August 20, 2013, Nikolai Plath wrote:

I'd like some custom fields (selects, check boxes, etc.) that can be
defined on a per project base.
And fore the canned queries - @vietvh https://github.com/vietvh still
with us ?

Let's shoot out this v1 and see what people are missing... c'mon [image:
]

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

Here's how I see the workflow and this would apply to any repo/application/extension we are working with:

• An issue can be opened by anyone.
• An open issue must be verified otherwise it gets closed with a reason (unable to reproduce | other).
• A verified issue needs a pull request or it can be closed with a reason (will not fix | duplicate).
• A pull request is opened.
• A pull request needs a combination end-user and automated testing (travis).
• A pull request that fails testing can either remain open and be reworked, or be closed.
• A pull request that passes testing needs a final review (by the merge team).
• A pull request that fails merge review can either remain open and be reworked, or be closed.
• A pull request that passes merge review will be merged and the pull request is automatically closed.
• If an issue is completely resolved after the pull request is merged, it can be closed otherwise it remains open until there have been sufficient pull requests or follow-up to fix the problem.
• An issue that does not require a coding solution can be closed once a satisfactory resolution is achieved.

@pjwiseman are we covering everything now or something is still missing?

We have implemented almost everything here. Closing for now. If something is missing, create a new issue please ;)