Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the problem we are trying to solve #203

Closed
brianteeman opened this issue Nov 14, 2013 · 18 comments
Closed

What is the problem we are trying to solve #203

brianteeman opened this issue Nov 14, 2013 · 18 comments

Comments

@brianteeman
Copy link
Contributor

We need a single point of truth to manage issues, avoid repetition by posting in two places and ensure all comments are seen without following two places.

Joomlacode

offers us a workflow for managing issues that is proven over time and works well for reporters and testers but less so for developers. See http://prezi.com/fp4bdgg2lprx/joomla-bug-squad-process/. It is easy to give an issue a status and to filter issues based on the status

Github

offers us a great way to submit code and to review and comment directly on the code itself but no ability to record the status or categorise the issue

The problems are as follows

  1. Having two different systems with no single point of truth
  2. Email notifications and tracking (github is great, joomlacode is bad)
  3. The need to create an account on two different systems
  4. Searching existing issues to see if it has already been reported (both are bad)
  5. Labelling an issue with a category (joomlacode is good, github has none)
  6. Recording the status of an issue (joomlacode is good, github has none)
    [note: github has labels but ONLY a maintainer can apply them]
  7. Ease of creating an issue and ensuring it is well documented

Solving the problems

So what does jissues need to offer in order to completely replace joomlacode and are we there yet.

  1. 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
  2. Email notifications and the links in them come from github not jissues
  3. 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)
  4. Search works GREAT on jissues
  5. There is no categorisation available in jissues eg templates, libraries, javascript
  6. There is no status available (or i couldnt see it - ACL ?)
  7. 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.

TL:DR

jissues is a wrapper for github but doesnt remove the need for people to go to github to create a PR.
jissues doesnt offer the labelling and status fields that github lacks and joomlacode offers

jissues imho is only at version 0.50 ie it has 50% of the features/functionality that Joomla needs

@eddieajau
Copy link
Contributor

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.

@brianteeman
Copy link
Contributor Author

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

@eddieajau
Copy link
Contributor

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 ...

@brianteeman
Copy link
Contributor Author

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 GitHubhttps://github.com//issues/203#issuecomment-28477017
.

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

@eddieajau
Copy link
Contributor

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?

@brianteeman
Copy link
Contributor Author

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

@eddieajau
Copy link
Contributor

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.

@brianteeman
Copy link
Contributor Author

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

@eddieajau
Copy link
Contributor

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.

@Hackwar
Copy link
Member

Hackwar commented Nov 14, 2013

Maybe they make a special price for FOSS?

@mbabker
Copy link
Contributor

mbabker commented Nov 14, 2013

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 GitHubhttps://github.com//issues/203#issuecomment-28478065
.

@brianteeman
Copy link
Contributor Author

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.

@b2z
Copy link
Member

b2z commented Nov 14, 2013

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.

@mbabker
Copy link
Contributor

mbabker commented Nov 14, 2013

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.

@allenzhao
Copy link
Contributor

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!

@b2z
Copy link
Member

b2z commented Mar 13, 2014

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

@allenzhao
Copy link
Contributor

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

@b2z
Copy link
Member

b2z commented Sep 1, 2014

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

@b2z b2z closed this as completed Sep 25, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants