I think that's really good but I'll make a couple of observations.

Github has a problem turning issues into pull requests and/or merging issues

The way I think of it is that a pull request is a sub-flow within the handling of an issue. An issue is an outer wrapper. One or more pull requests could make up the solution a single issue. The other way to look at it is that the issue is the workflow to find a solution to a problem, and the pull request is a specific inner workflow to produce the code for the solution.

jissues imho is only at version 0.50

Semantic versioning makes no value judgement about how complete a "thing" is. For what it's worth, we could argue this is 2.0, being the second incarnation of issue tracking in the project. Long story short, it doesn't matter what the exact numbers are, just that there are rules about how the version progresses.

it has 50% of the features/functionality that Joomla needs

But, not withstanding the good work that has been done, that comment is probably a little generous.

Remember I am only talking about this from the viewpoint of the CMS which has a userbase that is less technically savvy/skilled than the framework for example.

I 100% take what you are saying about the PR being a subset of the Issue but I just dont believe that workflow will hold up for the CMS

Hrm. Any thoughts on how we can black box the complexity? I mean, yeah, my team at work make Github sing, but expecting that of Joe Average is a tall order. Twill require some thought ...

Thats the core of the problem - github in my opinion is designed for teams
of equals to work together.

jissues should aim to be the single place for the majority of your users.
In fact a tester/reporter should never have to go to github.com at all.

On 14 November 2013 11:32, Andrew Eddie notifications@github.com wrote:

Hrm. Any thoughts on how we can black box the complexity? I mean, yeah, my
team at work make Github sing, but expecting that of Joe Average is a tall
order. Twill require some thought ...

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

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

In fact a tester/reporter should never have to go to github.com at all

I totally agree. So how do you think we could make that experience appear seamless to someone who doesn't appreciate what's going on under the hood?

to start I would look at
Point 2 above email notifications only from issues not github - dont know if that can be easily achieved
Point 3 above creating an account would be a start and easy to achieve

Point 2 above email notifications only from issues not github - dont know if that can be easily achieved

Oh I read that wrong. I don't think that's going to be possible.

Obviously that would only be for those users who are "only" using github for jissues - those people whose account is created on github by jissues

I guess I was hoping that if we are able to create the account for them through an api we would also be able to tell github to disable notification as well (thats a config option after all) so they would receive emails from jissues only.

I wold classify this as a really really nice to have but not a show stopper like the other stuff

On 14 November 2013 21:52, Brian Teeman notifications@github.com wrote:

I guess I was hoping that if we are able to create the account for them
through an api we would also be able to tell github to disable notification
as well (thats a config option after all) so they would receive emails from
jissues only.

Yeah, that's what you'd have to do, and it would be a bit of mucking around
because we'd then have to take over some of the services Github gives us
for free. Well, heh, the other way to solve it would be for the project to
use Github Enterprise and host is at something like github.joomla.org ...
ouch, 25K for 100 seats - ok, forget that.

Maybe they make a special price for FOSS?

We aren't actually creating GitHub accounts, just implementing the OAuth
login based on their documentation. Which brings me to another thought in
that I was thinking to use GitHub to handle e-mail and not the tracker
since it's already present. But that is something that can be thought
through as time progresses.

I'll catch up on everything else on this thread as the day progresses, but
wanted to at least brain dump on this topic.

On Thu, Nov 14, 2013 at 5:52 AM, Brian Teeman notifications@github.comwrote:

Obviously that would only be for those users who are "only" using github
for jissues - those people whose account is created on github by jissues

I guess I was hoping that if we are able to create the account for them
through an api we would also be able to tell github to disable notification
as well (thats a config option after all) so they would receive emails from
jissues only.

I wold classify this as a really really nice to have but not a show
stopper like the other stuff

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

Yes I realise we dont create the accounts and I believe it would be good if we did for those that dont already have one. One less site to visit.

but currently it uses vanilla markdown with a pretty crummy toolbar. GFM (Github Flavoured Markdown) is much better and makes formatting and inserting images a breeze.

Well, the text is parsed with the GFM so you can use it in the comments. The only miss currently is images, which I hope to solve in the nearest time.
You may blame the J!Tracker Application for transmitting this comment.

Github has a problem turning issues into pull requests and/or merging issues so we can end up with multiple issues for the same problem

This is an issue every project using GitHub has had to address. Best thing we can do here is look at some of them (Bootstrap for example) to see how they handle it and decide on a procedure before making the switch.

Email notifications and the links in them come from github not jissues

If we implement a notification system, we run the risk of spamming users with several e-mails per activity. The Notifications API doesn't allow you to do much about that.

Accounts - you need to only use a github account BUT for a new user with no github account they are taken offsite to create this. WE should use the github api to create the account on our site (assuming this is possible)

Just at a quick glance in the API docs, nothing stands out as allowing us this level of control.

Search works GREAT on jissues

And we want it to continue doing so while improving along the way.

There is no categorisation available in jissues eg templates, libraries, javascript

It was present in an older incarnation of the code but has obviously been lost along the way. This is probably one of a few pieces that we will need to (re-)implement.

There is no status available (or i couldnt see it - ACL ?)\

Display or edit? If edit, then yes, there is a bit of ACL in place. I've created groups with edit rights on the CMS and Tracker projects and assigned you to each. BTW @elkuku - like the group management area, an EXTREMELY GREAT improvement over Joomlacode.

Currently everything is only open/close because that's what GitHub can handle, but as we migrate over and get to work,

We have seen that feature requests created in github has much richer documentation and images etc than joomlacode which is awesome. I had hoped that the github experience would be present in jissues but currently it uses vanilla markdown with a pretty crummy toolbar. GFM (Github Flavoured Markdown) is much better and makes formatting and inserting images a breeze.

We actually are using GFM, one of the issues is in the template (code snippets in the app are getting the Bootstrap based styling which sucks compared to what you see on some of the items here). The editor that's in place could be improved, agreed.

Recording the status of an issue (joomlacode is good, github has none) [note: github has labels but ONLY a maintainer can apply them]

And this is something the app can workaround. Using the API and a bot account, a user in our app can manage labels and think they're updating GitHub when it's in reality being done by a proxy account.

jissues is a wrapper for github but doesnt remove the need for people to go to github to create a PR.

I'm fairly certain this could be accomplished in our UI using the API, we would just need to get the information needed to do so.

After reading the discussions above I just got more ideas about my GSoC project, like:
Allowing user to edit the labels,
Improve the editor,
Auto-generating PRs,
Catagories
So I'm thinking of adding some of them into my GSoC project.
I think Allowing user to edit the labels and catagories are interesting. Any thoughts or comments?
Thanks!

Yeap. I would say that Categories should be implemented ASAP, because they are vital for JBS workflow. But we need to find a way how to map them as labels. See #317

So I guess it's time to discuss about this issue again?

@allenzhao we should implement #449 first and then we can close it ;)