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
Comments
I think that's really good but I'll make a couple of observations.
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.
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.
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 jissues should aim to be the single place for the majority of your users. On 14 November 2013 11:32, Andrew Eddie notifications@github.com wrote:
Brian Teeman |
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 |
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:
|
Maybe they make a special price for FOSS? |
We aren't actually creating GitHub accounts, just implementing the OAuth I'll catch up on everything else on this thread as the day progresses, but On Thu, Nov 14, 2013 at 5:52 AM, Brian Teeman notifications@github.comwrote:
|
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. |
Well, the text is parsed with the GFM so you can use it in the comments. The only miss currently is |
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.
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.
Just at a quick glance in the API docs, nothing stands out as allowing us this level of control.
And we want it to continue doing so while improving along the way.
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.
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 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.
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.
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: |
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 ;) |
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
[note: github has labels but ONLY a maintainer can apply them]
Solving the problems
So what does jissues need to offer in order to completely replace joomlacode and are we there yet.
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
The text was updated successfully, but these errors were encountered: