Retiring JoomlaCode trackers

[Andrew Eddie]

I think we are past the question of "if" so I'd like to discuss "when" we can turn off the issue and feature tracking on JoomlaCode.

We also have the situation where we have different procedures for different sub-projects (CMS, Framework, Issue Tracker) so it would be good to unify how we work with "bugs" regardless of which piece of software we are using.

I realise the New Issue Tracker (NIT?) is not quite ready, but I'm wondering if just getting used to a Github workflow would be worse than today's double-handling?

I we can live with Github as a stop-gap, which I believe we can, how can we make that work?

Here's some suggestions on how it could work, and we really have to work this stuff out anyway for the NIT:

* Use labels to show a blended priority and impact setting:

P1-Urgent (Software stops working, bad security issues)

P2-High (Software working but seriously impeded, less-bad security issues)

P3-Normal

P4-Low

* Use labels to show category (beginning with a slash), eg:

/Administator, /Installation, etc

* Use milestones and the natural separation of Issues and Pull Requests to map the workflow. To this end I'd suggest the following:

- New issues are Open with no milestone.

- A confirmed issue (comment with #confirmed) moves to a "Confirmed" milestone

- All pull requests are automatically considered ready for testing. PR's must link to an issue they fix or address if one exists.

- Anyone who tests a PR and it passes comments with a #test or #tested.

- A PR that is tests moves to a "Review Ready" milestone where it awaits the commit team to review.

The one caveat here is that Github needs pull rights to change labels and milestones. So we either need a new team who can do that, and/or we fast-track triage team features in the NIT. At worst, we could have Jools do that work for us (we do have that technology).

I would also change the testing requirements to the following:

- Unless specified otherwise, PR's require 2 good tests.

- Changes to non-code text (DocBlocks, language strings, etc) do not need any testers and go straight to "Review Ready"

- The pull team may ask for more testers where the degree of change or impact warrants it.

* Optionally use labels to show a degree of complexity, more so people can identify easy bugs to fix. I work with a Fabonacci sequence and prefix with a tidle, so it goes like ~1, ~2, ~3, ~5, ~8 ... and it would roughly translate into hours but it really means that a ~8 bug is 8 times more difficult or time consuming that a ~1.

   

* Use special labels for backlog (things we should have done but didn't get around to) and new tasks or wish lists (things we could or should do).

Thoughts?

Regards,
Andrew Eddie

[brian teeman]

The BIG problem with labels is that github acl is woefully lacking and the only people who can apply a label are those with Maintainer access rights

[Andrew Eddie]

On 29 November 2013 10:23, brian teeman <joom...@googlemail.com> wrote:
> The BIG problem with labels is that github acl is woefully lacking and the
> only people who can apply a label are those with Maintainer access rights

Yes, I know. But is that worse than dropping JoomlaCode out of the
workflow altogether, and I could talk to Ian about seeing if Jools can
help.

Regards,
Andrew Eddie

[Dmitry Rekun]

Sounds interesting, but wouldn't it be too complex using the labels only? May be categories would help to structurize the items?

Dmitry

[Andrew Eddie]

On 29 November 2013 16:05, Dmitry Rekun <bzz...@gmail.com> wrote:
> Sounds interesting, but wouldn't it be too complex using the labels only? May be categories would help to structurize the items?

I'm working on the assumption that you are trying to store as much
information on Github as possible, even though in the NIT you might be
exposing it as different API. So, for example, in the NIT, you map a
list of labels to what the UI calls "Categories".

This maximises your flexibility and allows you to apply the NIT to
other sub-projects, not just the CMS and it maybe generates external
interest in it as well. It also scales well to be able to add
additional faceting (categories, priorities, impact, severity,
whatever) and still have the information stored on Github. The only
thing the NIT is really doing is supplementing the access control
system on Github.

And it's actually not that complex when you have a system to the
labels, but what the NIT is doing is changing how you expose all that
underlying data to be more friendly to people that don't live and
breath issue trackers, give you different reporting options, etc and
so on.

At the end of the day though, we still need to have a discussion about
our bug workflow and hopefully make it consistent across all parts of
the project whether they use the NIT or not.

Regards,
Andrew Eddie

[jms]

The general problem I see is that we would anyway keep a double system (even if are implemented the basic functionnalities of JC for the status, etc., and if the github UI is drastically improved), as Issues AND PRs will be separated.

So we could have Issues never looked at (yes, this may also be the case with JC), but, also, PRs without Issues which is not the case with JC.

I do agree though that we can't go on this way as it is quite impossible to follow up stuff on github AND JC at the same time just because some people prefer one to the other.
JM

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

-- 

Please keep the Subject wording in your answers

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the

intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies.

-----------------------------------------------------------

Jean-Marie Simonet  /  infograf768

Joomla Production Working group

Joomla! Translation Coordination Team 

[Andrew Eddie]

On 29 November 2013 17:41, jms <infog...@gmail.com> wrote:
> I do agree though that we can't go on this way as it is quite impossible to
> follow up stuff on github AND JC at the same time just because some people
> prefer one to the other.

Yes, this is the main problem. The double handing is not as bad
because what Github does is provide a workflow to review the "patch".

So where can we go from here? Is it possible to just use Github while
we wait for the NIT. I mean, seriously, the backlog is so huge it's
daunting to try and make sure everything is syncronised with
JoomlaCode. I'd even be willing to help get over the big hump but I'm
not interested in touching JoomlaCode.

Can we looking at changing the test rules for "text" changes?

Can we stop accepting new issues on JoomlaCode and start transitioning
over to 100% Github?

Regards,
Andrew Eddie

[Dmitry Rekun]

Do not forget that we have some open discussions already:
https://github.com/joomla/jissues/issues/6
https://github.com/joomla/jissues/issues/203

Dmitry

пятница, 29 ноября 2013 г., 8:36:00 UTC+2 пользователь Andrew Eddie написал:

On 29 November 2013 16:05, Dmitry Rekun <bzz...@gmail.com> wrote:
> Sounds interesting, but wouldn't it be too complex using the labels only? May be categories would help to structurize the items?

[Bakual]

If you create a PR, an corresponding issue is automatically created and linked by GitHub as far as I know. If you look at the GitHub page, you'll see all PRs also in the Issues section with the same comments and everything. So this should not be a problem at all. It's actually better than today with JoomlaCode :)

[brian teeman]

Unfortunately it doesn't work the other way

[Vic Drover]

So it's still an improvement over Joomlacode, yes ? 

On Friday, November 29, 2013, brian teeman wrote:

Unfortunately it doesn't work the other way

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

--

Cheers,

Victor Drover
Founder and CEO, Anything Digital LLC (BBB Accredited)
Co-founder, Watchful.li
262-309-4140
 @AnythingDig | @watchfulli

[brian teeman]

On Friday, 29 November 2013 17:48:38 UTC, Vic Drover wrote:

So it's still an improvement over Joomlacode, yes ? 

No not really its just different. If you create an issue on github then there is no easy way to link it to a pull request so you still end up with two seperate items relating to the same issue. The one where the issue is reported and the other where a solution is proposed. So we still end up with discussion etc taking place in two different places

 

On Friday, November 29, 2013, brian teeman wrote:

Unfortunately it doesn't work the other way

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

[Vic Drover]

In terms of GHOST sync, 1-way is better than 0-way IMO.

On Friday, November 29, 2013, brian teeman wrote:

On Friday, 29 November 2013 17:48:38 UTC, Vic Drover wrote:

So it's still an improvement over Joomlacode, yes ? 

No not really. its just different

 

On Friday, November 29, 2013, brian teeman wrote:

Unfortunately it doesn't work the other way

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

--

Cheers,

Victor Drover
Founder and CEO, Anything Digital LLC (BBB Accredited)
Co-founder, Watchful.li
262-309-4140
 @AnythingDig | @watchfulli

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

[kisswebdesign]

If you create an issue on github then there is no easy way to link it to a pull request so you still end up with two seperate items relating to the same issue. The one where the issue is reported and the other where a solution is proposed. So we still end up with discussion etc taking place in two different places

Actually there is an easy way to link PR's to issues...

https://help.github.com/articles/closing-issues-via-commit-messages#closing-issues-with-pull-requests

States

By including the "closed" keywords into the description of your Pull Requests, you can close issues. Just like with commit messages, if the bug isn't fixed to your default branch, the issue remains open. The issue is automatically closed only when the pull request is merged into your default branch.

you can use any of the keywords below in the PR description

• close
• closes
• closed
• fix
• fixes
• fixed
• resolve
• resolves
• resolved

So a when you create a PR that fixes issue number 666 you could put

fixes #666

in the PR description.

Simples!

[Andrew Eddie]

On 30 November 2013 04:55, kisswebdesign

<chris.jo...@kisswebdesign.co.uk> wrote:
> Actually there is an easy way to link PR's to issues...
>
> https://help.github.com/articles/closing-issues-via-commit-messages#closing-issues-with-pull-requests

Right. And what you need to get your head around is that Github treats
"reporting" an issue different from the workflow required to
"evaluate" the coding solution. It makes it very easy to solve several
issues with one pull request. As Chris mentioned, you just go:

Fixes #345
Fixes #346
Fixes #402

And when that PR is merged, it automatically closes the issues.

The Github API does allow for an issue to be converted into a PR, but
having used Github for several years I wouldn't advocate that anyway.
I think it's good to have a separation between what people report and
how those issues are fixed. Of course, I can also just issue a pull
request without a separate issue and that's terribly convenient for
someone who finds a problem and then has the knowledge to fix it. So,
Brian, when you find all those grammar mistakes, the only thing you'll
do is issue a pull request now.

So we get back to the question of who is deciding when we can turn off
JoomlaCode issue tracker? What's holding us back from just doing this?
We are in a perfect time to do this. 3.2 is out, we are only
concentrating on bug fixing. It's nearing a holiday time when everyone
is busy with life anyway. Will those opposing this please show their
hands, otherwise let's just do it. I'd rather spent time writing up
procedure for Github than debating edge points (however fun that might
be).

Regards,
Andrew Eddie

[brian teeman]

Andrew I think you will find that I have contributed more to the whole codebase and bugtracker process than just "grammar mistakes" and I find that comment offensive. You clearly have an issue today with making offensive comments and I wish you would think before you posted them.

You are asking for a show of hands about switching off joomlacode today well I am raising my hand AND helping with the new issue tracker to try and identify areas for improvement and completion before we can just "turn it off".

(Signing off for the weekend)

[Andrew Eddie]

On 30 November 2013 07:29, brian teeman <joom...@googlemail.com> wrote:
> Andrew I think you will find that I have contributed more to the whole
> codebase and bugtracker process than just "grammar mistakes" and I find that
> comment offensive. You clearly have an issue today with making offensive
> comments and I wish you would think before you posted them.

*sigh* assumptions are a terrible thing. The point was that you don't
have to make an issue AND a PR. That's all. I will make a point of not
picking on your in future lest you take offence where malignancy was
not intended.

> You are asking for a show of hands about switching off joomlacode today well
> I am raising my hand AND helping with the new issue tracker to try and
> identify areas for improvement and completion before we can just "turn it
> off".

Yes, and you are doing an amazing job. Please clone yourself, we need
more of you. Did I just say that?

Regards,
Andrew Eddie

[Bakual]

I would love to shut down JC. But we really should wait for JIssues to be complete. Otherwise we switch now to a new workflow and in a month we adjust the workflow again with an added tool. With all the confusion that will generate I'd say lets wait till JIssues is ready and then switch asap. It doesn't really matter when we wait a bit more.

[Hannes Papenberg]

I would support closing JC now. I mean, we will need a transitional time
where we allow to still manage existing items, but not to create new
ones (if that is possible with JC) but I think it would help us all to
switch as soon as possible, even if JIssues is not done yet. It might
even help finalize JIssues sooner, since it gets more attention.

I for one am following the project, but since I did not use it yet, I
somehow also did not get involved in the development. I guess when I'm
using it and I got itches to scratch, I would also force myself to
contribute...

Is there even a finalized version for JIssues? I know you say its not
ready yet, but in the end I guess its more like a moving target than a
one-time-install-and-then-never-to-looked-at-again thing. So when its
moving target, we might as well use it now. :-)

Hannes

[Matt Thomas]

For anyone following this thread, you can start using it now as part of the current workflow. Just head over to http://issues.joomla.org/. As with the CMS, the more people using, testing, and contributing to it, the better we will all be.

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Sent from mobile. Please excuse any typos and brevity.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

[Matt Thomas]

Just to clarity, my note foes not mean that we are not using JC anymore, but that JIssues is usable now.

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Sent from mobile. Please excuse any typos and brevity.

[Andrew Eddie]

On Saturday, 30 November 2013, Bakual wrote:

I would love to shut down JC. But we really should wait for JIssues to be complete. 

Tha t would be ideal but I reckon it's at least 3 or 4 months off being "ready" and that's not a negative reflection on the effort that's being put into it (sick of having to qualify intent to not offend). 

But the reality is the GitHub workflow still has to make sense so I don't see any point in waiting. 

Regards

Andrew Eddie 

--

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - free tutorials and videos on Joomla development

[jms]

+1 on this.

Rushing has always created more problems than solved.

JM

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

-- 

[Andrew Eddie]

On 30 November 2013 15:11, jms

> +1 on this.
> Rushing has always created more problems than solved.

The NIT has been in the works for over a year now, at least, and the
discussion to solve the deficiencies in JoomlaCode predates even that.
How much longer do we have to talk about this before we aren't rushing
- another year or two or three?

The minute you stop forcing people to use JoomlaCode, I guarantee that
you will see an increase in productivity. I for one will contribute to
fixing problems in the CMS again (I don't have the patience to fight
with JoomlaCode's antiquated way of handling things) - and I'm not
alone. The NIT is just icing on the cake but you still have to get
your workflows to work on Github itself. So I plead with you to stop
putting it off until the last possible second (I did not like the
change to git and Github at first, but I trusted that it was the right
decision and bit the bullet - no regrets in hindsight - I ask you to
do the same). It (keeping JoomlaCode alive) is hurting the project.

Regards,
Andrew Eddie

[Michael Babker]

So ironically, every time I say I'm going to spend some time focusing on the tracker, I get stuck doing damage control for a CMS release or working on my own smaller projects because a third party API broke them or real life pulls me away.  Fact is, with volunteers who come and go as they are able, nobody can define when the tracker will be at the point we would like it to be before switching without employing a couple folks to finish it on a contracted deadline.  And that also assumes the GitHub API doesn't make a large change as they've done in the last couple of months which has us having to re-evaluate some of the architecture.

I want to switch, I want to see the doors opened back up to the folks who detest JoomlaCode so much they'd rather not contribute, but I don't want to rush it.  Considering this is the second iteration of the tracker (remember we basically had a development reboot in April to adapt the Framework), the things that have been accomplished since then with the unique feature set it has now (the friendlier UI compared to JoomlaCode, international friendly UI, user voting on issue importance, better developer tools built into the system than could be imagined in today's CMS, even inbuilt documentation) have been awesome.  There's just some refining that needs to be made to get it to v1.0 "right" (meaning it works, it's stable, but it isn't the end state that we're shooting for).

Also remember, it's not done once we get to v1.0 or a point where we are ready to switch (whether that be v2.0 or some other version number).  There's an ambitious roadmap (http://developer.joomla.org/tracker/roadmap.html) for things we want to do with the tracker application and site as a whole later on to improve the user experience and make contributing fun.

My advice since day 1 has always been we need to focus on the tracker piece of the full application and make sure that its workflow is logical and we aren't dropping features that JoomlaCode offers us now.  So we need to be able to quickly gather key bits of data, flag issues certain ways, and filter those issues as we desire (basic examples, but hopefully my point is made).  So if you have some time, jump on the application as Brian has been doing, give feedback, and if you have the skill, dust off your IDE and throw some code our way.

Regards,
Andrew Eddie

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

[Andrew Eddie]

I'm still of the mind that you need to set a date to turn off
JoomlaCode issues. If you don't, those that don't want to change will
do nothing to help because it's in their best interest to delay the
inevitable for as long as possible.

Regards,
Andrew Eddie

[George Wilson]

I agree with Michael and the others. We need to make sure we have a much better workflow for dealing with issues - aside from the 2/3 months we should be waiting for to track bugs.

I've been really busy the last month or so - but the couple of issues I have used the tracker for have been relatively positive. The one thing I don't like with github is the hardness of attaching a PR to a issue. I mean sure you can link them - but then you have 2 'issue' items. I've learnt to do it in git but that took me weeks and sizeable proportion of people is just going to be a no go

Kind Regards,

George

[Andrew Eddie]

On 2 December 2013 09:43, George Wilson

<georgeja...@googlemail.com> wrote:
> I agree with Michael and the others. We need to make sure we have a much
> better workflow for dealing with issues - aside from the 2/3 months we
> should be waiting for to track bugs.

But the "better workflow" only comes from discussing what it's going
to me. I'm at a complete loss as to "where" to discuss it.

> I've been really busy the last month or so - but the couple of issues I have
> used the tracker for have been relatively positive. The one thing I don't
> like with github is the hardness of attaching a PR to a issue. I mean sure
> you can link them - but then you have 2 'issue' items. I've learnt to do it
> in git but that took me weeks and sizeable proportion of people is just
> going to be a no go

The reason is very logical. There is a workflow to assess an issue,
and there is a workflow to review code. You can, however, convert an
issue into a pull request via the Github developer API. However, the
big problem with converting an issue into a pull request is what if
the code was wrong? Closing the PR closes the original issue and you
are stuck. Leaving the issue as is allows multiple possible solutions
(it's not unusual for more than one person to provide a patch to fix
some things in different ways).

In my mind here's the UX.

* I'm browsing Github or the issue tracker and find an issue I can fix.
* I navigate to the file on the Github source tree and click "edit"
and go through the Github flow for editing a file and creating a pull
request automatically.
* I put in the description "Fixes #123".

OR

* I'm browsing Github or the issue tracker and find an issue I can fix.
* I update my local fork
* I find find the offending code and push a patch branch
* I go to my fork on Github and click the "Make a pull request" button
that automatically appears.
* I type "Fixes #123" into the description

The pull request on Github and the patch file on JoomlaCode are
exactly the same thing, but JoomlaCode provides no ability to review a
patch file. Additionally, any meta text about the patch file is buried
in JoomlaCode's terrible comment handling system (and lets not even
start on the email that JoomlaCode sends out). Github provides
automatic linking to other PR's and issues as long as you include the
#123 numbers.

I go back to my original point that swapping to just Github and
ironing out your workflow is much better than persevering with this
crazy hybrid arrangement. I don't see how anyone can argue that we
are rushing into change when we are already using the system. Rushing
into dropping one step out of the process ... really?

Before:

* MockUser (lest anyone get offended if I pick on them) raises issue on Github
* MockUser is told they has to raise it again on JoomlaCode
* MockUser's issue is resolved and is closed on Github.
* "Someone" determines that JoomlaCode issue can now be closed as well
and someone has to visit JoomlaCode to do it.

* MockDeveloper raises a PR on Github for a fix.
* MockDeveloper is told they must also raise the same thing on JoomlaCode.
* MockDeveloper's code is merged. Github automatically closes the PR.
* MockDeveloper has visit JoomlaCode (log in twice because of that
stupid bug) and make a comment that issue can be closed.
* JBS has to visit JoomlaCode to close the issue.

After:

* MockUser (lest anyone get offended if I pick on them) raises issue on Github
* MockUser's issue is resolved and is closed on Github.

* MockDeveloper raises a PR on Github for a fix.
* MockDeveloper's code is merged. Github automatically closes the PR.

Note the above is an oversimplification looking at the points where
JoomlaCode is an unnecessary hinderance to the workflow (and that's
not even touching the insanity of two conversations about the same
issue in two different places) - it's like driving your car with your
hand-brake on.

Regards,
Andrew Eddie

[George Wilson]

Oh no definitely here is the point to define a workflow :D I'm just saying I don't agree with us moving across immediately. JoomlaCode should definitely still being used at the moment.

I'm still not convinced the methodology you described above is easier than JoomlaCode (for starters the workflow of a committer is to close JoomlaCode and GitHub issue - so that's actually one item for example). By the time you have categories, number of testers required, what branch the PR is against (plus other things I'm sure I've forgotton) immediately your being confronted with enough labels comments and cross references if there have been multiple attempts to fix the issue - it will fry your brain!

Also what's this log in twice JoomlaCode Bug? I definitely don't have that??

Also certainly until the dropdown sorting is fixed on the NIT (and maybe even categories assigned to new items) I think it's completely unacceptable to be telling users reporting bugs to use it. It's unfair on them to try and find if and issue already exists. Also the ability of JBS members to increase priorities (I'm guessing you currently need github label permissions) needs to be fixed. Especially the latter issue from my limited understanding is no quick fix

I think the other thing your missing is what to do when our number of PR's etc. blows through the roof. Currently only a couple of hundred PR's on github. We're constantly getting more PR's than testing so we're going to start running into huge numbers of PR's/issues out of date sitting around - which GitHub solves no easier than JoomlaCode does now.

Kind Regards,
George

Regards,
Andrew Eddie

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/55ydvr6Ekvo/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Andrew Eddie]

On 2 December 2013 11:44, George Wilson>

> I'm still not convinced the methodology you described above is easier than
> JoomlaCode (for starters the workflow of a committer is to close JoomlaCode
> and GitHub issue - so that's actually one item for example).

It's still two steps, one on the Github site and one on the JoomlaCode
site. The point is we are no longer coding on JoomlaCode so this is an
extra step no matter how you slice it.

> By the time you
> have categories, number of testers required, what branch the PR is against
> (plus other things I'm sure I've forgotton) immediately your being
> confronted with enough labels comments and cross references if there have
> been multiple attempts to fix the issue - it will fry your brain!

Well, it doesn't fry your brain but if it does I would suggest that
the workflow is too complicated and needs to be simplified. This is
why I separate workflow with milestones from categorisation with
labels. You are working with exactly the same data on the Issue
Tracker but you have control over how you present it. But you still
need to know what it all means.

> Also what's this log in twice JoomlaCode Bug? I definitely don't have that??

Long standing issue that the password form misfires.

> Also certainly until the dropdown sorting is fixed on the NIT (and maybe
> even categories assigned to new items) I think it's completely unacceptable
> to be telling users reporting bugs to use it. It's unfair on them to try and
> find if and issue already exists. Also the ability of JBS members to
> increase priorities (I'm guessing you currently need github label
> permissions) needs to be fixed. Especially the latter issue from my limited
> understanding is no quick fix

Have we actually asked them or are we just making the assumption?

> I think the other thing your missing is what to do when our number of PR's
> etc. blows through the roof. Currently only a couple of hundred PR's on
> github. We're constantly getting more PR's than testing so we're going to
> start running into huge numbers of PR's/issues out of date sitting around -
> which GitHub solves no easier than JoomlaCode does now.

So you are saying that if you run all your PR's and issues on the
JIssues repo through JoomlaCode it won't affect your productivity or
your sanity? George, I've also been around for a while and processed
my fair share of contribution so I know how hard it is and I know how
much HARDER JoomlaCode is making the process. There has been more than
enough time to transition.

I give up.

Regards,
Andrew Eddie

[Michael Babker]

On Sun, Dec 1, 2013 at 7:44 PM, George Wilson <georgeja...@googlemail.com> wrote:

Also certainly until the dropdown sorting is fixed on the NIT (and maybe even categories assigned to new items) I think it's completely unacceptable to be telling users reporting bugs to use it. It's unfair on them to try and find if and issue already exists. Also the ability of JBS members to increase priorities (I'm guessing you currently need github label permissions) needs to be fixed. Especially the latter issue from my limited understanding is no quick fix

We need more folks reporting UI issues, or just UI people in general jumping in on the tracker and helping out with that.  The entire interface is designed by developers and admittedly sucks (and there's only a handful of views actually publicly accessible; the stuff that only us devs are really seeing is just as bad, I promise).  And unless I've missed it (possible, I've lost count of the things I'm supposed to be paying attention to anymore), I don't think I've seen those specific items noted on the issue tracker's issue tracker.  Know some stuff is a work in progress (we know the ACL needs some major tuning, we know the UI needs A LOT of attention, and we know there's some data we would like that isn't in the workflow yet, like categories), but unless you see it somewhere being discussed or committed, raise an issue so it doesn't get past us.

I think the other thing your missing is what to do when our number of PR's etc. blows through the roof. Currently only a couple of hundred PR's on github. We're constantly getting more PR's than testing so we're going to start running into huge numbers of PR's/issues out of date sitting around - which GitHub solves no easier than JoomlaCode does now.

This is no worse than the situation now with GitHub and JoomlaCode.  There are 485 open issues on GitHub (464 are pulls) and 626 items in an open status on the JoomlaCode issue tracker alone.  This is an argument just for the sake of arguing IMO; software alone is not going to do something about the number of open items, it's going to take a lot of man hours to work through or somebody throwing the "I don't care" switch and arbitrarily closing anything with no activity in the last X days.

[George Wilson]

On Monday, December 2, 2013 2:36:48 AM UTC, Michael Babker wrote:

On Sun, Dec 1, 2013 at 7:44 PM, George Wilson <georgeja...@googlemail.com> wrote:

Also certainly until the dropdown sorting is fixed on the NIT (and maybe even categories assigned to new items) I think it's completely unacceptable to be telling users reporting bugs to use it. It's unfair on them to try and find if and issue already exists. Also the ability of JBS members to increase priorities (I'm guessing you currently need github label permissions) needs to be fixed. Especially the latter issue from my limited understanding is no quick fix

We need more folks reporting UI issues, or just UI people in general jumping in on the tracker and helping out with that.  The entire interface is designed by developers and admittedly sucks (and there's only a handful of views actually publicly accessible; the stuff that only us devs are really seeing is just as bad, I promise).  And unless I've missed it (possible, I've lost count of the things I'm supposed to be paying attention to anymore), I don't think I've seen those specific items noted on the issue tracker's issue tracker.  Know some stuff is a work in progress (we know the ACL needs some major tuning, we know the UI needs A LOT of attention, and we know there's some data we would like that isn't in the workflow yet, like categories), but unless you see it somewhere being discussed or committed, raise an issue so it doesn't get past us.

Been meaning to! I've been at a (politics) conference all weekend so I'm still catching up on mailing lists and stuff. 

 

I think the other thing your missing is what to do when our number of PR's etc. blows through the roof. Currently only a couple of hundred PR's on github. We're constantly getting more PR's than testing so we're going to start running into huge numbers of PR's/issues out of date sitting around - which GitHub solves no easier than JoomlaCode does now.

This is no worse than the situation now with GitHub and JoomlaCode.  There are 485 open issues on GitHub (464 are pulls) and 626 items in an open status on the JoomlaCode issue tracker alone.  This is an argument just for the sake of arguing IMO; software alone is not going to do something about the number of open items, it's going to take a lot of man hours to work through or somebody throwing the "I don't care" switch and arbitrarily closing anything with no activity in the last X days.

The switch should be thrown in my opinion. Generally if the issues haven't got attention then they are trivially small or have been fixed elsewhere. The one nice thing about github I would say is that if people still find it is an issue and want it back on the radar then they can always reopen the issue :)

Kind Regards,

George 

[Dmitry Rekun]

Well for me we are in the middle of something currently with the Issues Tracker. We need a plan for v1 to be released. Please throw your thoughts here: https://github.com/joomla/jissues/issues/253

Thanks!

Dmitry

[Al Warren]

I don't come around much but I'll throw my two cents in anyway. You guys don't know me but I've been in the background for a few years. Prior to Github, you had a system that basically tracked issues, fixes, and commits. You log an issue. Folks discuss it. They dig into the code, find a fix, post a patch, test it, and if it passes muster, it gets committed.

Now enter Github. You're basically doing the same thing there. And on the tracker. You're doubling your efforts for the same end result. That can only halve production. Now enter JIssues. You try to automate the Github part and wind up with a custom solution that you'll have to spend time and effort maintaining. I suspect any effort (time) gained using automation will be negated by the maintenance you'll have to do on JIssues. I know, it'll be perfect when it's finished, right? No maintenance needed until Github changes the API. Sure.

You guys have been around long enough to know software is never perfect and needs constant maintenance. And you want to add an additional project to manage just so your can use "your" platform. It basically does the same thing as the thing we "automate" with one crucial difference. You don't have to maintain Github.

For the life of me, I cannot see any logical reason to double the effort to achieve the same result. I can see some emotional and ownership issues. But, how does that contribute to productivity? Personally, I would drop both the tracker AND JIssues and get on with the business of managing the project(s). But that's just me. Maybe I'm missing something.

Whatever. I'm sure I'll read about it on Twitter considering I don't contribute.

[Bakual]

The problem with GitHub only is that you can't really use "states" like we currently use in JoomlaCode. So something as how many tests done and "Ready to Commit". Also it's not possible to add "categories" for the issues. Yes, you can use labels for that, but you need push access to assign those.

That's what we try to solve with JIssues. It's a hook which could add those filtering so it's then easier to look for PRs which are ready to merge for example.

We currently have over 400 PRs open on GitHub alone. And on JoomlaCode it's even worse facing around 600 "open" issues. We need something to triage that stuff. GitHub alone does work nice if you have a handful of PRs and the maintainers can handle most of it. But with our amount of PRs and Issues, it's just not gonna work imho.

[Andrew Eddie]

On 8 December 2013 06:53, Bakual <werbe...@bakual.ch> wrote:
> The problem with GitHub only is that you can't really use "states" like we
> currently use in JoomlaCode.

That is not true. Github only has two states Open and Closed just like
JoomlaCode. What JoomlaCode does is allow you to classify more and
align them with the true "Open" or "Closed" state. But I think
JoomlaCode is wrong because it's trying to manage state and workflow
in the one field. You can solve this nicely on Github by using the
Milestones. You only need a few:

* Confirmed
* Ready for Review

How simple is that?

> So something as how many tests done and "Ready
> to Commit".

See above. As for testing, I suggest you have people use the hash tag
#test or #tested. We can write a bot to search for these.

> Also it's not possible to add "categories" for the issues.

Again not true. Labels are not ideal but neither is out current
situation of using two trackers. You just need to develop a system.
Here's the one I use for the Developer Doc repo:

https://github.com/joomla/joomla-developer-docs/wiki/Issue-Tracking

Again, I say not ideal but it keeps everything within the
functionality of Github. All JIssues needs to do is map "labels" to
groups of lists, either manually in the short term or via the db.

> Yes,
> you can use labels for that, but you need push access to assign those.

That is correct and I've spoken at length with Github about this.
Hopefully we can have this resolved next year. But in the mean time we
are still between a rock and a hard place and JIssues is going to take
time to finish. So let's please compromise to get some forward motion
and do the following:

1. Set up a new team in Github called "CMS Triage Team" or similar.
2. Add to this team the PLT, the Framework maintainers (because you
are going to ask them to help for a sprint) and then a small trusted
group of JBS people that are under strict instruction to never, ever
hit the merge button (you already have that case now with some
people).
3. Whack all these people in a Skype chat (this is one time where it
is actually useful to use Skype) so they can coordinate.
4. Blitz the backlog with extreme prejudice.

> That's what we try to solve with JIssues. It's a hook which could add those
> filtering so it's then easier to look for PRs which are ready to merge for
> example.

Yes, but I'm of the strong opinion that your system needs to work on
Github without JIssues. If JIssues tries to do anything too fancy,
it's going to end up in integration hell. But the fact remains,
JIssues doesn't make the work of triaging the issues any easier. You
still have to eye-ball them all. So let's start practicing the
workflow in Github and then breath a sigh of relief, for some, when
JIssues finally releases (and I've of the opinion that the PLT will
need to hire a contractor to get a lot of the fiddly bits finished in
a timely manner).

> We currently have over 400 PRs open on GitHub alone. And on JoomlaCode it's
> even worse facing around 600 "open" issues. We need something to triage that
> stuff. GitHub alone does work nice if you have a handful of PRs and the
> maintainers can handle most of it. But with our amount of PRs and Issues,
> it's just not gonna work imho.

I disagree. I moved from Jira (not dissimilar to JoomlaCode) to Github
at work and our productivity went through the roof. Our backlog is not
as big but we'd probably handle at least half the throughput it you
were keeping up with the issues. What you need to triage is physical
eye-balls. No tool is going to help you do this automatically. I think
we just have to be ruthless and force close anything older than 6
months. Then do a second pass, and a third and a fourth. It's not
going to be easy, but I can tell you it will be a lot easier making
sure the backlog is clean just on Github than trying to do it on both
it and JoomlaCode.

> Am Samstag, 7. Dezember 2013 05:09:10 UTC+1 schrieb Al Warren:
>> For the life of me, I cannot see any logical reason to double the effort
>> to achieve the same result. I can see some emotional and ownership issues.
>> But, how does that contribute to productivity? Personally, I would drop both
>> the tracker AND JIssues and get on with the business of managing the
>> project(s). But that's just me. Maybe I'm missing something.

You aren't missing something and I completely agree. This is a time
where we just have to bite the bullet and start pushing forward.

We know JoomlaCode needs to be turned off. We know JIssues still has a
fair bit of work to get it finished (let's face it, it's being built
on "spare time"). Github can work for us **now**. Can we please just
compromise and move forward with it. People, it's that hard - but
keeping the status quo going is [much harder].

Regards,
Andrew Eddie

[Hannes Papenberg]

Regarding the backlog I'd like to say that I yesterday went through the PRs on github for about 3 hours and I was able to test and/or evaluate about 30 PRs, resulting in 14 of those being solved. Most time was lost in checking data both on github and JC, so having this on one tracker would definitely benefit. Yes, I chose some of this easier ones, but if all those that send in a PR also test one or two from someone else, we would get a lot further.

While writing this, I decided that I will test at least 2 PRs for every PR that I send in. I encourage everyone else to do the same. :-)

Is there some more substantiated stats on the issues tracked on JC? I'd like to get those issues transfered across to github. We will have to do that regardless of what we do. But we should try hard to filter out all those issues that are duplicates, superseded stuff, etc. I don't know the status of all current entries. Bakual said we had 400 PRs and 600 JC entries. Are those numbers real and how much do both sets overlap?

Hannes

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

[brian teeman]

At least I agree that the only solution is triage and eyeballs. Especially if it is done brutally.

[Andrew Eddie]

JoomlaCode:
* 636 open issues
* ~70 last modified before 1 July 2013 (about 560 modified this last half)
* ~270 last modified before 1 October 2013 (about 360 modified this
last quarter)

Github
* 463 open issues & PR's
* All issues modified this quarter
* ~120 issues created more than 6 months ago

Daunting to say the least. So, I'm actually not hearing any opposition
in this thread to closing JoomlaCode (yay). On that basis can we just
put it to a vote or something?

Here's what I propose in principle:

1. Stop new issues and features being added to JoomlaCode.
2. Draft an interim instructions for using Github only for handling
issues, pull requests (aka patches) and maybe new features as a lower
priority.
3. Close any issue or new feature in JoomlaCode that was modified
before 1 July this year (with a polite note).
4. Close any JoomlaCode issue that has a pull request and transfer the
information to Github.
5. Create a "Confirmed" and a "Ready for Review" milestone in Github
to acts as the workflow.
6. Create enough labels in Github to "get by" (as few as possible but no fewer).
7. Create a "JBS" team or similar in Github made up of trusted souls,
give them push access but with strict instructions not to merge.
8. Slash the backlog.

I propose a similar blitz on the feature tracker but I would expect
you'd want to using the /joomla-projects/joomla-cms tracker for
handling new features to keep them separate from the JBS. But let's
get the backlog down on issues first. Frankly, we should ignore all
new features until it's under control.

None of this work is lost and it needs to happen anyway for JIssues in
my opinion. The bottom line is change is required, so let's change and
stop procrastinating. The JIssue be the cavalry that rides in to say
the day in the nick of time (I suspect turning off JoomlaCode will
inject the necessary impetus for people to help improve it).

I'm willing to help with whatever provided JoomlaCode is shut[ting] down.

Regards,
Andrew Eddie


On 8 December 2013 08:59, brian teeman

[Webdongle]

Hi Andrew

Just 3 questions ...
Can average Joe Joomla just log in to Git and add a report bugs without creating pr's or installing software ?
Can talented amateurs help manage the trackers without creating or installing software pr's ?
If it's voted on then will the vote be publicised in the forum so that all Joomla users can vote ?

If the answer to any of those questions is yes ... then imho it would be a mistake to close the Joomlacode tracker.

From a non dev's viewpoint it looks like moving the developing to git has caused more problems than it solves.

[Hannes Papenberg]

*Can average Joe Joomla just log in to Git and add a report bugs without
creating pr's or installing software ?*
Yes. Login to Github, click on the issue tab in the Joomla repo and
click on New. Done.

*Can talented amateurs help manage the trackers without creating or
installing software pr's ?*
They will need a git software on their system. The same that they needed
an SVN software on their system when we were still using SVN.

*If it's voted on then will the vote be publicised in the forum so that
all Joomla users can vote ?*
The way I understood Andrew, he wanted an informal voting on this
mailinglist, as we've done several times in the past for different topics.

*From a non dev's viewpoint it looks like moving the developing to git
has caused more problems than it solves.*
If you mean that github is the issue, I can assure you, wholeheartedly
and with more than 100% confidence, that that is not the case. Using
github has solved so unbelievably many issues and raised productivity by
several orders of magnitude. It also improved the quality of commits all
over. The only issue that we created, was the double issue tracking both
on Joomlacode and on github. That was a mistake and needs to be fixed as
soon as possible. The only sensible solution for both users and
developers is to shut down Joomlacode. Because right now they not only
need a Joomlacode account (which wasn't possible to get at all times.)
but they also need a github account to comment further on a possible
solution for their issue.

A little question for Andrew: We still need to host our release packages
somewhere and I really also want to keep the whole release history from
1.0.0 onwards somewhere. When Joomla does not use Joomlacode anymore,
where would that stuff be hosted? I'd be happy to help out moving that
to a well documented system that has both the releases and their release
notes attached to them somewhere. Remember that you currently have to
login (and be a member of a Joomla WG?) to see all releases on JC.

Hannes

[Webdongle]

Hi Hannes

"*Can talented amateurs help manage the trackers without creating or
installing software pr's ?*
They will need a git software on their system. The same that they needed
an SVN software on their system when we were still using SVN."

Not sure if you understood my question ...
Myself and others can set the status of a report in the Joomlacode tracker without downloading software.  Just login, view the report, test the open report and change it's status to confirmed/more info required etc. ... Can that the status of a report be changed on git without creating or

installing software pr's ?

[Hannes Papenberg]

There is no such sing as "installing a software PR". A PR is a pull
request, a request to merge my code into your git repository. Normally
you open an issue and then someone comes along, creates a pull request
with reference to that issue and says that it will fix that issue. You
can then test that PR and say that your test worked or that it didn't.
As Andrew said, there is a shortcoming in github to be able to set flags
like we did on Joomlacode, but to be honest, I doubt that the issue will
be a big one. However, to test PRs, you need a git software to get the
actual patch merged into your system, the same that you needed
TortoiseSVN or something similar to test the code when we were using
SVN. Besides that we also got the patchtester component.

Long story short: Yes, you will have to install software to test
patches. No, that is not more difficult or more complex than before
moving to github, quite the opposite. No, you can not mark an issue as
confirmed or whatever right now, because we would need JIssues for that.
No, that wont be a problem and I'm pretty sure that we can find a simple
solution for that.

A solution would for example be to have a bot that scans the open
Issues/PRs every 15 Minutes or something and if someone (sufficiently
authorized) comments with a specific keyword, the bot sets a flag on the
item.

Hannes

> > an email to joomla-dev-cm...@googlegroups.com <javascript:>.

> > To post to this group, send an email to

> joomla-...@googlegroups.com <javascript:>.

> > Visit this group at
> http://groups.google.com/group/joomla-dev-cms

> <http://groups.google.com/group/joomla-dev-cms>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.
>

[Webdongle]

Hi Hannes

here is no such sing as "installing a software PR". A PR is a pull
request, a request to merge my code into your git repository.

Yes I know that

there is a shortcoming in github to be able to set flags
like we did on Joomlacode, but to be honest, I doubt that the issue will
be a big one.

It will because it will increase the work load of devs as many who help set issues will not be able to do it so easily on git.  You will loose helpers.

However, to test PRs, you need a git software to get the
actual patch merged into your system, the same that you needed
TortoiseSVN or something similar to test the code when we were using
SVN. Besides that we also got the patchtester component.

You miss the point ... I was not asking about testing patches.  I was speaking of the users who see an issue and test to see if the issue exists.
fyi TortoiseSVN can download from Git ... it just can't apply the patches.  So no extra software is needed to test if the Open report is PEBCAK or a bug.
But if git can not be used to prioritise bug reports then only devs will be handling the bug reports.

If you wish to restrict the handling of bug reports to devs and you do not want non devs to handle the reported bugs then move to git.

[Hannes Papenberg]

You are currently talking about one thing only: That you can't mark an
issue as confirmed in the overview list of all issues. Everyone can
comment on Issues and PRs. Everyone can write "I can confirm that
issue." What you can't do (and what only a very small "elite" can do) is
set labels on an issue/PR. I wouldn't call that a big issue, because
even without those labels, we would still have less workload if we don't
have to check github AND JC regarding this stuff. But even if that is an
issue for you, I'd say that we can solve the labeling issue simply by
adding a bot that reacts on keywords in github comments.

I doubt that people will go away simply because they can't put a sticker
on an item anymore, but have to write "I can confirm this issue"

Hannes

[Bakual]

That is not true. Github only has two states Open and Closed just like
JoomlaCode. What JoomlaCode does is allow you to classify more and
align them with the true "Open" or "Closed" state. But I think
JoomlaCode is wrong because it's trying to manage state and workflow
in the one field. You can solve this nicely on Github by using the
Milestones. You only need a few:

To my knowledge, milestones serve a completely different purpose. It's meant to group together multiple issues which for example block a release. Or to set a goal whit a date when those issues have to be solved. Then people can work toward that goal and get a nice progress bar showing how close they are.

It would for example be a good use for the current JIssues repo to list all blocking issues for the release of 1.0 (instead of the label currently used for that).

It can however also be solved using labels. And there is already work done toward this. Be it by JIssues or Brian who does a lot of this stuff already.

The creation of a triage team is a good idea to consider I think. It could maybe help till JIssues is ready.

The lacking GitHub ACL is imho the biggest point JIssues tries to solve.

I agree with you that the workflow basically should work without JIssues at all. The important information should stay in GitHub. JIssues should be a tool to make it easier to filter and search for specific issues, automate stuff (like tracking a #test codeword and then applying correct labels) and workaround the lacking ACL.

[Webdongle]

When patches became pr's a lot of non dev volunteers stopped testing fixes and as a result the issues in the tracker started piling up

With Joomlacode non dev volunteers can change the flag of a report ... but if that ability stops for them, then you dev's will have to manage the bug reports, test the fixes as well as develop Joomla.  The gap between the devs and non devs increases.

The mess you are in now with the plethora of unclosed bug reports is largely because of move to github.  That is what has caused the bottle neck in workflow.  Git is great for developers and works well for the platform ... but when it comes to the cms it kills the ability for non devs to help.

Moving the tracker to git will only compound the problems that have been caused by preventing non devs from testing fixes.

The problem is not with Joomlacode ... the problem with the bug report backlog is moving to git and loosing a lot of help from non devs. That broke the work flow now you want to break it even more.  It is so obvious that it begs the questions ... is there an agenda here that is not being stated ?  And are we going to end up with 2 Joomla's one commercial and a poor relative as a free version ?  The new extensions in JED are now mostly commercial .

The beauty of Joomla was that it provided a good product for professionals and non professionals alike and both contributed to it.  But now the cooperation between professionals and non professionals is less than it was.  Moving the tracker to github will be the next step to Joomla moving away from a product that both professionals and non professionals can both use.

[Webdongle]

Hi Bakual

The creation of a triage team is a good idea to consider I think. It could maybe help till JIssues is ready.

The lacking GitHub ACL is imho the biggest point JIssues tries to solve.

Excellent point

[Bakual]

Can average Joe Joomla just log in to Git and add a report bugs without creating pr's or installing software ?

Yes, that's easy. You need a GitHub account (like you needed one in JoomlaCode) and then you can create new Issues. You can format the text using markdown syntax (which is quite simple) and can drag'n drop pictures in it. You can't however select a category, branch, or anything else currently possible in the various dropdown lists on JoomlaCode. You would need to write this in the issue.

This is because GitHub only allows people with push access to assign labels. JIssues tries to solve this using a bot with push access.

Can talented amateurs help manage the trackers without creating or installing software pr's ?

In GitHub, no. As said you need push access to assign labels.

However again, JIssues tries to solve that with that bot.

 

If it's voted on then will the vote be publicised in the forum so that all Joomla users can vote ?

Actually, it probably will be a vote within PLT. You can of course vote wherever you want, but I think the PLT will have to make this decision in the end. Of course based on community feedback.

I think most don't really like JoomlaCode and the double handling we have. So shutting down JoomlaCode is not the problem. But we need to make sure the points you raised are addressed first. And JIssues tries to solve exactly this.

By the way: you can help test JIssues: http://issues.joomla.org/

[Bakual]

When patches became pr's a lot of non dev volunteers stopped testing fixes and as a result the issues in the tracker started piling up

With Joomlacode non dev volunteers can change the flag of a report ... but if that ability stops for them, then you dev's will have to manage the bug reports, test the fixes as well as develop Joomla.  The gap between the devs and non devs increases.

The mess you are in now with the plethora of unclosed bug reports is largely because of move to github.  That is what has caused the bottle neck in workflow.  Git is great for developers and works well for the platform ... but when it comes to the cms it kills the ability for non devs to help.

I acknowledge this problem. I think we are on the right track with com_patchtester which makes it very simple to test a PR for non-devs. At least the simpler ones.
I'm also in contact with the developer of SmartGit which led to massive improvements in his software which makes it easy to test PRs as well. You need to set up SmartGit onces, and after that you will have a nice GUI and can apply a PR to your local server with two mouseclicks. We're working on a good documentation for that as well. So that should get easier as well.

[Hannes Papenberg]

Believe me when I say that we had a lot more open bugs, which were
tested and fixed by a lot less people than today when we were still on
Joomlacode and SVN. We always had an issue with more bugs coming in than
being fixed and we actually have become better in the last few months
with this than ever before in the history of this project. Yes, people
might have left. But for each that left, two new ones have come aboard.

Hannes

[Andrew Eddie]

On 8 December 2013 20:05, Webdongle <in...@weblinksonline.co.uk> wrote:
> Just 3 questions ...
> Can average Joe Joomla just log in to Git and add a report bugs without
> creating pr's or installing software ?

You log into Github.com. Git is the command line application you would
install on your system, but you don't need it to access Github (Github
is a web site). You can report an issue without a pull request just
like you can report an issue on JoomlaCode without a patch. It's the
same concept.

> Can talented amateurs help manage the trackers without creating or
> installing software pr's ?

Well, you obviously need to install a web browser, but that's the bare
minimum. All the talented amateurs I know tend to *want* to install
software to make their life easy.

> If it's voted on then will the vote be publicised in the forum so that all
> Joomla users can vote ?

That was more a statement of frustration about how to decide when to
turn off JoomlaCode.

> If the answer to any of those questions is yes ... then imho it would be a
> mistake to close the Joomlacode tracker.

If you are smart enough to use JoomlaCode, you will find Github easier
overall. The JBS will probably find it a little more frustrating
initially because they'll be reminding people to note their Joomla
version et al.

> From a non dev's viewpoint it looks like moving the developing to git has
> caused more problems than it solves.

I'm sorry you feel that way. Many people have taken a lot of time to
try and work through your concerns but I'm at a loss as to how to help
you further.

Regards,
Andrew Eddie

[Andrew Eddie]

On 8 December 2013 22:24, Bakual

> To my knowledge, milestones serve a completely different purpose. It's meant
> to group together multiple issues which for example block a release.

The can, but in project management a milestone is simply a "stage". A
bug workflow is simply a series of milestones.

> The lacking GitHub ACL is imho the biggest point JIssues tries to solve.
> I agree with you that the workflow basically should work without JIssues at
> all.

I'm hopefully going to get a further opportunity to talk with Github about that.

Regards,
Andrew Eddie

[Webdongle]

Hi aAndrew

If you are smart enough to use JoomlaCode, you will find Github easier
overall.

For developing yes ... but for just applying patches/pr's ... I can say that downloading a patch and applying/reverting is easier than getting a PR to work.

I'm sorry you feel that way. Many people have taken a lot of time to
try and work through your concerns

Yes and I apologise to those people if my comments caused them offence.  JIssues and com_patch tester are perfect ... when will http://issues.joomla.org/ be officially announced as the url to report bugs ?

[Andrew Eddie]

On 8 December 2013 22:30, Webdongle

> The problem is not with Joomlacode ... the problem with the bug report
> backlog is moving to git and loosing a lot of help from non devs. That broke
> the work flow now you want to break it even more. It is so obvious that it
> begs the questions ... is there an agenda here that is not being stated ?
> And are we going to end up with 2 Joomla's one commercial and a poor
> relative as a free version ? The new extensions in JED are now mostly
> commercial .

I've heard far more creative conspiracy theories in my time. If you
don't want to use Github, then taking a line from Herb Kelleher, we'll
miss you.

Regards
Andrew Eddie

[Amy Stephen]

On Sunday, December 8, 2013 4:05:34 AM UTC-6, Webdongle wrote:

From a non dev's viewpoint it looks like moving the developing to git has caused more problems than it solves.

 

With respect, shouldn't the primary perspective considered be that of a developer? Aren't developers the ones who debug coding problems and create patches, and therefore use resources like github to share their work freely with open source projects?

It would be interesting to see how many patches this project loses because of the extra work developers have to take and the foreign environment they are required to use before a fix they freely provided is even considered.

Every few months, non-developers go through github and close PR's if there isn't a Joomlacode entry. It's mind-blowing to see real bug fixes flushed down the toilet. It should be pointed out, those same people are the ones who are constantly hollering out on Twitter -- "Don't listen to them, they don't contribute."

Well, when efforts are thrown away, why would you? I don't know of _any_ other project that requires a developer use two source code repository systems to report a bug and share a fix. If for whatever reason the workflow of this project is so uber complex that github can't accommodate and two repositories are absolutely required to get the patch in -- then, the "clean up old, ignored patches process" should be an act of creating the second entry instead of throwing away patches. Please.

I would like to thank Thomas and Hannes for saving some of my thrown away patches recently. You would not believe how much that encourages a developer.

[brian teeman]

On Sunday, 8 December 2013 12:30:56 UTC, Webdongle wrote:

When patches became pr's a lot of non dev volunteers stopped testing fixes and as a result the issues in the tracker started piling up

The facts dont show this - thats just your personal opinion.

Activity by contributor http://developer.joomla.org/activity-by-contributor.html

Total Bug Squad Activity By Type http://developer.joomla.org/total-activity-by-time-period.html

Total Open Issues by Status http://developer.joomla.org/total-open-issues-by-time-period.html

Open and Close Activity http://developer.joomla.org/open-closed-issues.html

 

[Matthew Baylor]

On Sunday, December 8, 2013 4:30:56 AM UTC-8, Webdongle wrote:
> The new extensions in JED are now mostly commercial .

Untrue. 106 of the last 200 published were non-commercial.

[Amy Stephen]

On Sunday, December 8, 2013 8:21:43 AM UTC-6, brian teeman wrote:

Open and Close Activity http://developer.joomla.org/open-closed-issues.html

 

The Open and Close Activity states:

Note: An issue in the tracker may be closed in one of two ways. It may be fixed with a code change, or it may be closed because it was a duplicate issue or not considered to be a bug.

A category should be added "Closed because there is no Joomlacode entry." That would help measure the bleed rate.

Further, the act of pasting in a standard "Thanks for your efforts but we are closing this without consideration", followed by the closing of a PR with contributed code really shouldn't count as a contribution in the Activity by Contributor. If someone creates a Joomlacode entry so the code can be considered, _that_ is a contribution. JMO, I guess.

http://developer.joomla.org/activity-by-contributor.html

[George Wilson]

Daunting to say the least. So, I'm actually not hearing any opposition
in this thread to closing JoomlaCode (yay). On that basis can we just
put it to a vote or something?

Here's what I propose in principle:

1. Stop new issues and features being added to JoomlaCode.
2. Draft an interim instructions for using Github only for handling
issues, pull requests (aka patches) and maybe new features as a lower
priority.
3. Close any issue or new feature in JoomlaCode that was modified
before 1 July this year (with a polite note).
4. Close any JoomlaCode issue that has a pull request and transfer the
information to Github.
5. Create a "Confirmed" and a "Ready for Review" milestone in Github
to acts as the workflow.
6. Create enough labels in Github to "get by" (as few as possible but no fewer).
7. Create a "JBS" team or similar in Github made up of trusted souls,
give them push access but with strict instructions not to merge.
8. Slash the backlog.

OK let me be absolutely clear what I meant. I am 100% against JoomlaCode closing until we have a defined system for the GitHub labelling workflow and a way for JBS people to set these labels. Obviously I support getting these labels fixed asap and THEN shutting JoomlaCode - but as far as I'm concerned it would be irresponsible to shut down JoomlaCode before we have a good working workflow in JIssues (i.e. I support 2-8 but only enact 1 after this has happened!)

Kind Regards,

George 

[Al Warren]

+1 for Andrew's response

If you can figure out how to use Joomla admin, the tracker, and a text editor, you can figure out how to use Github. Things change. Changes don't cause backlogs. People who refuse to change cause backlogs. They also don't cause a project to become commercialized. Not sure where that left field conspiracy theory came from.

[Tobias Gesellchen]

After only following this discussion and without good arguments for or against closing the JoomlaCode tracker, I would like to state that duplicating issues at GitHub and JoomlaCode violates the DRY principle.

Yes, I just applied a best practice for developers to an organizational workflow. Why? Because repeating oneself is waste. Maintaining nearly identical issues for the same problem or solution is waste. Telling developers that "submitting a pull request at GitHub isn't enough" is a waste of their time. Everyone would have to admit that it's not the usual way of using GitHub or JoomlaCode when one has to manually add a JoomlaCode tracker item, linking to it from the GitHub issue and then trying to follow both (?) items for comments or changes.

I also regard this discussion quite wasteful, as it doesn't seem to have only one question, but there are several arguments which divert from the post's title. It seems unclear how the familiar JoomlaCode workflow could be applied to GitHub. I still don't know what's the advantage of the JoomlaCode workflow. Why has it been established in the way it now is the status quo? How old are the virtues behind it and do they still have the same importance? Do we have other, probably more important aspects to regard when thinking about a better workflow?

From the outside this discussion looks like a dispute in a big old company but not like in an agile open source project. GitHub might be suboptimal for your needs, but I would like to know: how much workflow is necessary? Isn't change the only way to make progress?

I don't think that it would be a big risk to move on to GitHub. If anything doesn't work optimal I guess you can fix it. But you just have to do it and I know other developers would help, including myself. If you don't move on, less people will help.

As a concrete proposal I would suggest to set a date when to switch the old JoomlaCode tracker off. Having a date might have the risk of being later than expected. But people need dates to have a kind of motivation or pressure. Pressure often comes with a flow unless there's not too much resistance ;-)

Just my two cents.

Regards,

Tobias

[Michael Babker]

On Sun, Dec 8, 2013 at 7:18 AM, Webdongle <in...@weblinksonline.co.uk> wrote:

Hi aAndrew

If you are smart enough to use JoomlaCode, you will find Github easier
overall.

For developing yes ... but for just applying patches/pr's ... I can say that downloading a patch and applying/reverting is easier than getting a PR to work.

I think the issue you're running into with testing patches is that you're still using SVN but there is no way to make a GitHub pull request (which can be downloaded as a Git patch) apply as a SVN patch.  There's only so much we as a project can do to help you in this situation, com_patchtester works independent of Git or SVN.  Ultimately though, to be able to work with some more complex patches (i.e. things that require you to reinstall), you will eventually need to learn to use a tool like TortoiseGit or SmartGit.

If you've never actually looked at the GitHub issue tracker (not JIssues as I see you were testing it earlier), check out https://github.com/joomla/joomla-cms/issues/2649 for an existing item and https://github.com/joomla/joomla-cms/issues/new for the new item form.  From a UX perspective, GitHub is much friendlier.  From an admin perspective in working with JBS, the predefined data that we'd lose by only using GitHub (which JIssues is covering) can hurt the workflow for a project like us.

[Hannes Papenberg]

Hi Michael et al,
I know we want to achieve quite a lot with JIssues, but maybe we can
have a quick'n'dirty interim solution where we define a list of
usernames that are allowed to set tags and when a user with that
username comments on an item and uses a specific keyword, that tag is
set by a bot that is run by a cron job every 15 minutes. It should be
possible to implement that in an afternoon, especially considering that
most of the code is already in JIssues. Do something like ?test_success
or ?confirmed or ?test_fail as keywords and that would be it. Prepending
with a - would remove the tag again.

With that we could switch off JC in a week and have something to have a
similar workflow like in JC. We will need JIssues in the longterm, but
we also need to switch of JC in the shortterm. Maybe that would be a
solution to this timing problem.

Hannes

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to joomla-dev-cm...@googlegroups.com.
> To post to this group, send an email to joomla-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/groups/opt_out.

[Andrew Eddie]

On 9 December 2013 04:55, Tobias Gesellchen

> > I also regard this discussion quite wasteful, as it doesn't seem to have
> only one question, but there are several arguments which divert from the
> post's title.

Agreed, so let's get it back on track. Here's my proposed backlog for
two initial phases. I'm hosting them on the JIssue repo because I
believe the process of dealing with issues is just as important as
writing the code for the JIssues tracker.

Phase 1: https://github.com/joomla/jissues/issues?milestone=3&state=open
Phase 2: https://github.com/joomla/jissues/issues?milestone=4&state=open

Phase 1 is aggressive - develop interim guidelines in a week and then
stop accepting new issues on JoomlaCode.

Let me draw your attention to the two most important things:

https://github.com/joomla/jissues/issues/256 - define the new workflow
https://github.com/joomla/jissues/issues/257 - define how to use labels

Phase 2 more or less turns JoomlaCode off at the end of February 2014.

This is reasonable and doable. Both these phases are needed regardless
of when JIssues launches officially (and I can't see that happening
until late first quarter 2014 anyway so that fits perfectly).

If there are other "tasks" you think are needed, just add them to the
tracker and I'll file them in the right spot.

I really think everyone who cares about the CMS or it's future need to
down tools and concentrate on one of the following for the next 3
months:

1. The Bcrypt bug fix.
2. Cleaning up the issue backlog
3. Testing or helping with the new issue tracker (which includes
nailing down workflows, etc).

We are bleeding out and the problems aren't going to go away unless we
reign things in.

Just to be clear, keeping JoomlaCode open is not on the table as far
as I'm aware. It's not a question of "if" but "when" to turn it off.
You don't have to like git or Github, but the project is revolving
around it regardless. Please keep the conversation constructive (that
is, how can you make the most out of Github even if you don't like it,
what information do you need to master it, etc and so no).

Thanks in advance for you careful consideration, and hopefully help.

Regards,
Andrew Eddie

[George Wilson]

I think this is a good plan. May I suggest as we seem to have failed to start using the staging branch after the release of 3.2 that in your plans as JoomlaCode shuts we move to staging branch? Or do we just leave this for Joomla 4.x?

Kind Regards,

George

[Michael Babker]

We're going to start using it, but more pressing issues made that switch less of a priority.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

[Andrew Eddie]

On 9 December 2013 11:06, George Wilson

<georgeja...@googlemail.com> wrote:
> I think this is a good plan. May I suggest as we seem to have failed to
> start using the staging branch after the release of 3.2 that in your plans
> as JoomlaCode shuts we move to staging branch? Or do we just leave this for
> Joomla 4.x?

Actually at work I've ditched the staging branch and we just merge to
master now, because the of the CI integration (inspired by
http://scottchacon.com/2011/08/31/github-flow.html - everyone still
works in forks though). Personally I wouldn't bother and I'd like to
get the Framework done the same way. Either way, and like Michael
says, a priority for another day.

Regards,
Andrew Eddie

[Matt Thomas]

On Sun, Dec 8, 2013 at 8:41 PM, Andrew Eddie <mamboblue@gmail.com> wrote:

Actually at work I've ditched the staging branch and we just merge to
master now, because the of the CI integration (inspired by
http://scottchacon.com/2011/08/31/github-flow.html - everyone still
works in forks though).

I was quietly wondering the same thing. One team that I work with has done the same, ditched staging/develop, and that does simplify the process. A simple git branching model seems to follow the same basic idea.

 

[David Hurley]

I like this approach quite a bit... My concern is the deployments. We do not push me versions with the same level of frequency (although I would like to).

This would make it hard for software versions where people have to update their website frequently (as stated here 24 time in a day).

What is the workaround? The entire system relies on that rapid release to minimize potential failures or introduced bugs.

Thanks,
David Hurley

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

[David Hurley]

Stupid autocorrect -

We don't push NEW versions with the same level of frequency.

Sorry for the confusion.

Thanks,
David Hurley

[Andrew Eddie]

On 9 December 2013 12:33, David Hurley

> I like this approach quite a bit... My concern is the deployments. We do not
> push me versions with the same level of frequency (although I would like
> to).

I don't understand what a "me" version is (hate autocorrect).

> This would make it hard for software versions where people have to update
> their website frequently (as stated here 24 time in a day).

The reality is we don't have the capacity to push that many versions
like WordPress can do to wordpress.com or even I do internally at
work. But merging to master instead of staging doesn't change much in
the workflow at all. The difference is that, prior to Travis, our CI
was done after the merge, so you needed to stage those changes in a
branch before it went to master. Now that we have Travis doing CI on
pull requests themselves (replacing our old pull tester and then
some), we can relax a little bit about merging directly to master.

> What is the workaround? The entire system relies on that rapid release to
> minimize potential failures or introduced bugs.

No, it doesn't affect your release schedule at all. The only thing
that has changed is when the CI tools run (and you obviously run them
again after the merge to double check).

Regards,
Andrew Eddie

[Andrew Eddie]

Draft proposal for issue and pull request workflow. Note this is
written from the perspective of an onlooker.
https://gist.github.com/eddieajau/5f9d83b1325b1a3d880a

Draft management guidelines (labelling and workflow):
https://gist.github.com/eddieajau/fdcdd5e607adce0a3f6d

Note that I'd left out priority and replaced that concept with
"impact". The idea here is that your "priority" is to clear out issues
with impact 1 first, then 2 then 3 then 4.

Please don't use the gist comments - notifications don't work so you
may not get a reply.

Regards,
Andrew Eddie

[Gary Jay Brooks]

2 cents if this adds up to any type of vote or motion towards a goal.

I read this thread (wow lots of passion) and everyone all had some nice points.  However some of you are afraid of acting, we should not work on our "afraid feelings".  It might be wise that we invest some of our Joomla dollars to fly a team together to make plans for this important transition, or we trust a single mastermind to make the plans for the transition and we iterate as a team using a Google doc or docs on GitHub (I think that's the current workflow).   Its clear that one system and a new workflow is required, having 2 separate systems has always been confusing to new people.  If we want to be "friendly" we need 1 system like GitHub.  If we want to be more advanced we an use the GitHub API to expose our workflow differently. For example https://sprint.ly/ heavily changes the view of the data from GitHub and associates workflow tracking. If we have a lack of workflow we can create our own systems using the GitHub API just like Sprint.ly.  We can fight the good fight but at the end of the day think getting rid of the current Joomla tracker needs to be a planned karate chop move done fast, so we can keep the new team moving smart.  To keep it simple, I say we study another project larger then us that 100% uses GitHub and has the workflow setup for us to learn from. 

@garyjaybrooks

[Andrew Eddie]

On 10 December 2013 15:32, Gary Jay Brooks <garyb...@cloudaccess.net> wrote:
> To keep it simple, I say we study
> another project larger then us that 100% uses GitHub and has the workflow
> setup for us to learn from.

I'm finding it hard to find a project that competes more than us (see
https://github.com/joomla/joomla-cms/graphs/contributors).

Symfony
https://github.com/symfony/symfony/issues?direction=asc&sort=created&state=open
http://symfony.com/doc/current/contributing/code/bugs.html

AngularJS
https://github.com/angular/angular.js/issues

Magento
https://github.com/magento/magento2/issues

phpBB, Drupal, WordPress, jQuery - issues not managed on Github

Oh, interesting:
https://github.com/angular/angular.js/pull/5344

Automated check on the CLA and some other things - VERY COOL!

Regards,
Andrew Eddie

[Bakual]

What's the advantage of using milestones over labels? I think the same could be achieved with labels alone.

Or do I miss something?

We would also have to make sure it doesn't go against how JIssues tries to handle things.

[Andrew Eddie]

On 10 December 2013 18:40, Bakual <werbe...@bakual.ch> wrote:
> What's the advantage of using milestones over labels? I think the same could
> be achieved with labels alone.
> Or do I miss something?

To me the milestone is useful to show what "stage" of the workflow are
you in, but you are right, you could do the same thing with labels.

> We would also have to make sure it doesn't go against how JIssues tries to
> handle things.

This is part of the thinking I'm also trying to draw out. To me
JIssues should just be supplementing what Github already provides and
give you different views of the base data that are more friendly and
more useful to our specific needs. But, if we are trying to change the
way that Github naturally handles things, we should drop the Github
integration altogether (not a good plan in my opinion but it is an
option).

Regards,
Andrew Eddie

[Patrick Studio 42]

I expose a real situation.
I'm so to say a beginner on using github and don't use it all time.
I have do a major change to solve a probleme with form fields. Currently you cannot change the render of form fileds but with the new JlayoutRender you can.

I have, for now, made a new branch on my github https://github.com/studio42/joomla-cms/tree/jlayout-formfields, because i know i do some mistakes and the code have to be tested. But i know some agree for the need of this code, just one current problem is that bootstrap 3 does not render correctly form fields vecause missing class "form-control" but can be solved with this code.

I think making a pull request is to too early, but this code is a must have for template maker(not only for bootstrap 3)

Now how to solve my problem?

If i make a new issue in JoomlaCode trackers i have to do a pull request, right?

But the code is not ready to use.

If i don't add a PR and an issue in the tracker, no one kow i work on this and why.

This mean at end, perhaps, i work for nothing !
(sorry for my poor english)

[Bakual]

You can always do the JoomlaCode item, even without a PR. You can also reference your branch there if you like.

Or you just create the PR and update it over time. That's also possible and easier to test.

If possible, I would keep the PR simple and only do a few fields with one PR. So it's easier to test and faster to implement than if you change everything within one PR.

[Hannes Papenberg]

It's been 2 months and while I tested a bunch of PRs, I again felt the
pain that Joomlacode is providing us. I've logged into github once and
that was it. For JCode, I gotta do that basically every day. I look at
the github PRs and Issues and they are way better to handle, even
without JIssues and tags and all the fields that we have currently...
And, no offense Brian, but posting into every second PR that we need a
JCode tracker item, isn't really raising the morals. Looking at for
example the PRs from gunjanpatel, he has 18 codestyle fixes, 14 of which
have no JCode tracker item. Should I go and paste that request to open
tracker items for those 14 PRs or could we simply accept them and handle
them without JCode? We've requested it from him for the other 4 PRs,
where it is equally unnecessary.

Long story short: Please PLT, reconsider closing the Joomla JCode
Tracker and move to github completely NOW. :-)

Hannes

Am 13.12.2013 22:14, schrieb Bakual:
> You can always do the JoomlaCode item, even without a PR. You can also
> reference your branch there if you like.
> Or you just create the PR and update it over time. That's also
> possible and easier to test.
>
> If possible, I would keep the PR simple and only do a few fields with
> one PR. So it's easier to test and faster to implement than if you
> change everything within one PR.
>
> Am Freitag, 13. Dezember 2013 16:48:20 UTC+1 schrieb Patrick Studio 42:
>
> I expose a real situation.
> I'm so to say a beginner on using github and don't use it all time.
> I have do a major change to solve a probleme with form fields.
> Currently you cannot change the render of form fileds but with the
> new JlayoutRender you can.
> I have, for now, made a new branch on my
> github https://github.com/studio42/joomla-cms/tree/jlayout-formfields

> <https://github.com/studio42/joomla-cms/tree/jlayout-formfields>,

> because i know i do some mistakes and the code have to be tested.
> But i know some agree for the need of this code, just one current
> problem is that bootstrap 3 does not render correctly form fields
> vecause missing class "form-control" but can be solved with this code.
> I think making a pull request is to too early, but this code is a
> must have for template maker(not only for bootstrap 3)
> Now how to solve my problem?
> If i make a new issue in JoomlaCode trackers i have to do a pull
> request, right?
> But the code is not ready to use.
> If i don't add a PR and an issue in the tracker, no one kow i work
> on this and why.
> This mean at end, perhaps, i work for nothing !
> (sorry for my poor english)
>

[Leo Lammerink]

I fully agree with Hannes. It will mean we will have a lot of open
issues left but better start with a clean open list than keeping all the
stuff from the past open so for me I think it would be a blessing

+ 1000

Leo

[Hannes Papenberg]

I'd already be happy if we didn't allow new tracker items and then
slowly worked of the old ones. Anything new goes into github.

Hannes

[Leo Lammerink]

Reason why i said as such is that we have me think tons of unconfirmed
issues on the Tracker..... So why not just close it and start with a
fresh list? All that has been posted as 'bugs' will be posted again and
we can start with a fresh list so nothing wrong me think? You know as
wel as I know that "slowly working them off" sounds like..... won't
work for sure? ;-)

Leo

[Dmitry Rekun]

Here is the list of tasks regarding JC closure by Andrew Eddie. Feel free to discuss there ;)

Dmitry

пятница, 7 февраля 2014 г., 21:05:30 UTC+2 пользователь Leo Lammerink написал:

[brian teeman]

@Hannes 

I havent posted anything on github or joomlacode for about 4 months. Regarding the codestyle fixes it was already stated by the PLT (decided) that they didnt need joomlacode items

Everytime you start a sentence with no offence it means that you are intending to cause offence. So please don't

[Hannes Papenberg]

Sorry Brian, I didn't want to offend you, but was simply searching for an example where we waste energy.

[Bakual]

It's still considered to move to JIssues. We don't have to reconsider that :)

There was a problem with JIssues related to some changes in the GitHub API which threw us a bit back. But it's looking good again.

There's also a list of open issues for JIssues one could have a look at and try to fix: https://github.com/joomla/jissues/issues?labels=&milestone=&page=1&state=open

That would help push that move forward.