Production Goals for 2013 Published

[Michael Babker]

On behalf of the PLT, I am pleased to announce that the production goals for 2013 have been published and are available for viewing at http://developer.joomla.org/news/552-production-goals-for-2013.html.

We welcome and encourage feedback on our published goals for the year.  We ask that you please use this thread for any discussion.

Thank you,

Michael Babker

Production Leadership Team

[Paul Orwig]

Thanks Michael, to you and everyone else on PLT for coming up with this great set of goals! 2013 is going to be a really strong one for Joomla.

Best,

paul

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

[kisswebdesign]

Thanks, it is good to see that there are goals (and what they are) for this year - it really helps to see what is happening behind the scenes. Making these things visible can only improve perceptions.

Specific feedback...

Goal #1: Complete Three Iterations of the Joomla Platform Project.

OK, 3 versions this year. Who will consume these versions?

I am unsure of who these releases are for. Which version is being targeted for use by the CMS, for example

1.1 Define and Ratify the Version and Deprecation Strategy for the Platform.

Useful, thanks.

1.2 Implement Tools to Assist with Collaboration

I have seen talk about Jira on the platform dev group, but I think Joomla should use Github.

Github has been chosen as the tool for source control, and has the ability to do everything needed for collaborative development. Why use 2 tools when one will do.

Also, Jira is a closed source, proprietary, commercial (ie you pay for it, per user) product - and that seems to be at odds with Joomla Key values http://www.joomla.org/about-joomla/the-project/mission-vision-and-values.html#keyvalues 

1.3 Introduce Namespacing

Excellent :-)

1.4 Lift Code Coverage for Each Package to a Minimum of 50%

Very useful :-)

1.5 Add Complete Documentation for 5 New Packages in the Platform Manual

Yes please :-)

Goal #2: Complete two full iterations of the Joomla CMS project.

Good to see target dates and version numbers.

2.1 Lift Code Coverage for the CMS Libraries to 30%

Anything that improves code quality is a good thing.

2.2 Enforce Joomla Coding Standards in All CMS Files

Why have coding standards if they are not followed. Of course bringing legacy code into line just for the sake of it (ie it adds no real value) is not something I would prioritise.

If a file is being worked on (bug fix, security, feature add, etc) then the whole file should be bought into line at that time.

2.3 Enforce Test Compliance Pre-Commit

Sounds like a good plan. Would like to see a comprehensive guide to testing joomla - what tools to use, scripts, etc. to go along with this.

The last thing Joomla needs is to make it harder for people to contribute.

Goal #3: Release maintenance updates to the current LTS and STS releases as required.

Goes without saying :-)

Goal #4: Outreach and promotion of Joomla to a technical audience.

Yes :-)

4.1 Participate in Google Summer of Code program

Yes :-)

4.2 Review and improve developer.joomla.org

Yes please. :-)

Goal #5: Improve processes in Translating the Joomla Software and support the enhancement of the Joomla CMS multilingual system.

Yes :-)

As an English speaking English person I have no ability in translating anything to other languages and rely on others (or babelfish) to understand anything non-english. I guess this is the same for all single-langauge speakers. So making sure things are translated / translatable to other languages is a bonus - and would only benefit anything Joomla related in expanding the potential market.

Goal #6: Refine and improve the user contribution process.

Yes, please make it easier to contribute. The current process sucks, and acts as a dis-incentive to contributing.

In switching to github the whole process should have moved to github too, not have 2 unlinked tools - with separate logins - that require copy/paste from one to the other with reference numbers, etc.

Please simplify the contribution process, for the CMS, platform and new framework. Make them follow the same process, and use as few tools as possible (ie one).

If there are external requirements or additions to the end of the contribution process (like packagist for the framework https://packagist.org/search/?q=joomla) then make this an add-on process controlled by repository maintainers, and not integral to the contribution process.

--

Just my thoughts / feedback

Chris.

[Amy Stephen]

1.2 Implement Tools to Assist with Collaboration

I have seen talk about Jira on the platform dev group, but I think Joomla should use Github.

Github has been chosen as the tool for source control, and has the ability to do everything needed for collaborative development. Why use 2 tools when one will do.

Also, Jira is a closed source, proprietary, commercial (ie you pay for it, per user) product - and that seems to be at odds with Joomla Key values http://www.joomla.org/about-joomla/the-project/mission-vision-and-values.html#keyvalues 

No one would use two tools if one can do, that would be crazy. Since I do not understand all of the project management needs for the platform team and leadership, I would hesitate to project whether or not an environment could satisfy those needs.

Jira is not commercial for Joomla, Jira has shared unlimited license with Joomla as they do with open source projects who request this. This has also been discussed in the platform threads.

As you know from the discussions, the test Jira environment came from the initiative a specific community member invested to explore the environment for Joomla. Right now, the project is stalled as the volunteer has not had time to move it forward. I have no idea if it will be used or not by the project.

Regarding Key Values, I assume you are referring to the Key value of "Freedom"?

If so, here is the description:

"Freedom" was chosen as our topmost value for many reasons. We want to give people the freedom to build Web sites with which to publish their ideas. We want to give people the freedom to collaborate with others in their own language. And we want to give people the freedom to use, copy, modify, and distribute the code and protect those freedoms using the GNU/GPL. We also want to provide people with the freedom to be a part of the community and to participate in the future development of the project. - See more at: http://www.joomla.org/about-joomla/the-project/mission-vision-and-values.html#keyvalues

The only element of freedom I see as relevant (since we would not be distributing Jira), is the last one:

freedom to be a part of the community and to participate in the future development of the project

Freedom" was chosen as our topmost value for many reasons. We want to give people the freedom to build Web sites with which to publish their ideas. We want to give people the freedom to collaborate with others in their own language. And we want to give people the freedom to use, copy, modify, and distribute the code and protect those freedoms using the GNU/GPL. We also want to provide people with the freedom to be a part of the community and to participate in the future development of the project. - See more at: http://www.joomla.org/about-joomla/the-project/mission-vision-and-values.html#keyvalues

I know for certain that the community member has given consideration to how to interact with the broader community. If it were used, people would not be shut out, the tool would help enable participation.

There is no key value to only use free software. That would be pretty limiting as many of the environments and tools used are not open source. Github isn't open source. So, using it for project tracking wouldn't take care of the freedom issue. Even our version of JoomlaCode is proprietary. Most of us use proprietary computer operating systems. Many of us use phpStorm or Sublime 3. Anyone not use Skype? Not open source.

The important aspect of licensing is what is distributed: Joomla and its extensions, uses the GPL and this, of course, does not impact it.

[Michael Babker]

On Thursday, 28 February 2013 06:49:57 UTC-6, kisswebdesign wrote:

Goal #1: Complete Three Iterations of the Joomla Platform Project.

OK, 3 versions this year. Who will consume these versions?

I am unsure of who these releases are for. Which version is being targeted for use by the CMS, for example

Just a note here that the goals were written and defined prior to the Framework being implemented and that path being taken, as noted by Andrew elsewhere.

As for which version the CMS will use, the goal is to update the CMS to the latest Platform version with each release, with some exceptions.  Whatever Platform code was in CMS 3.0 when it was released will remain until 4.0 per the CMS deprecation strategy (only major releases allow backwards compatibility breaks, such as removing code).  So, code removed from the Platform has to be kept in the CMS files, meaning it isn't just a simple copy/paste between repos.  As well, we customized many of the JHtml classes while working on the Bootstrap integration, so that's another area that requires a bit more focus.  Lastly, we don't just merge the Platform in blindly, but typically will do patches following the Bug Squad workflow to get us in sync (sometimes, folks will port over small features as they need them, and as we get closer to release, we'll do bigger patches porting over more of the Platform code to get in sync).  This will become less of a concern as the Platform is officially reintegrated into the CMS, at which point the discussion should shift to how we can integrate pieces of the new Framework into the CMS.  But, that discussion should be saved for another thread down the road.

 

2.2 Enforce Joomla Coding Standards in All CMS Files

Why have coding standards if they are not followed. Of course bringing legacy code into line just for the sake of it (ie it adds no real value) is not something I would prioritise.

If a file is being worked on (bug fix, security, feature add, etc) then the whole file should be bought into line at that time.

A few people who commit to the CMS are doing just that, and at the same time, we work on larger changes to break some of the codestyle exceptions that can be committed without test.  A recent one was enforcing that all classnames are declared with a leading capital letter, something that all the plugins (i.e. plgSystemDebug) didn't do, and a change we could make without going through the workflow for testing.  Also, we don't want to make these changes in large batches so that our update packages aren't needlessly large with modified files that only changed due to codestyle, so those types of efforts are usually saved for the beginning of the year when we have to change the copyright in every file's header and near a major or minor release.  In the weeks leading into CMS 3.1, this would be a good time to work on improving the enforcement of codestyle rules.

 

Just my thoughts / feedback

Chris.

Thanks for the feedback! 

[Brad Gies]

Just as an FYI. I used JIRA when I worked as a contractor for Disney. It's a little complex to setup, and has a bit of a learning curve, but it really is excellent at keeping track of projects, and helps PM's and programmers tremendously to break things down into small blocks of work.

The main problem the Joomla community would have with JIRA is that you need someone to be leading the team, and getting things into JIRA, and I'm not sure that would happen. It would be great for larger projects though if it was used (and continually updated). It gives a great overview of exactly what's happening at any given moment.

So.. my feedback on JIRA is "Great Tool", great for managed projects... not sure it would work for the Joomla! community. I do get the feeling the platform guys would use it and love it though. I really don't think the CMS would see much benefit.

My 2c.

Brad.

[kisswebdesign]

Jira is not commercial for Joomla, Jira has shared unlimited license with Joomla as they do with open source projects who request this. This has also been discussed in the platform threads.

OK, this is good to know (and I'll try to remember in future).

 

As you know from the discussions, the test Jira environment came from the initiative a specific community member invested to explore the environment for Joomla. Right now, the project is stalled as the volunteer has not had time to move it forward. I have no idea if it will be used or not by the project.

It may have stalled, but Jira is still mentioned in the 2013 goals - so I wanted to reflect my thoughts about using it. My overriding thought is 'sledgehammer to crack a walnut'

 

Regarding Key Values, I assume you are referring to the Key value of "Freedom"?

If so, here is the description:

"Freedom" was chosen as our topmost value for many reasons. We want to give people the freedom to build Web sites with which to publish their ideas. We want to give people the freedom to collaborate with others in their own language. And we want to give people the freedom to use, copy, modify, and distribute the code and protect those freedoms using the GNU/GPL. We also want to provide people with the freedom to be a part of the community and to participate in the future development of the project. - See more at: http://www.joomla.org/about-joomla/the-project/mission-vision-and-values.html#keyvalues

The only element of freedom I see as relevant (since we would not be distributing Jira), is the last one:

freedom to be a part of the community and to participate in the future development of the project

Freedom" was chosen as our topmost value for many reasons. We want to give people the freedom to build Web sites with which to publish their ideas. We want to give people the freedom to collaborate with others in their own language. And we want to give people the freedom to use, copy, modify, and distribute the code and protect those freedoms using the GNU/GPL. We also want to provide people with the freedom to be a part of the community and to participate in the future development of the project. - See more at: http://www.joomla.org/about-joomla/the-project/mission-vision-and-values.html#keyvalues

I know for certain that the community member has given consideration to how to interact with the broader community. If it were used, people would not be shut out, the tool would help enable participation.

There is no key value to only use free software. That would be pretty limiting as many of the environments and tools used are not open source. Github isn't open source. So, using it for project tracking wouldn't take care of the freedom issue. Even our version of JoomlaCode is proprietary. Most of us use proprietary computer operating systems. Many of us use phpStorm or Sublime 3. Anyone not use Skype? Not open source.

The important aspect of licensing is what is distributed: Joomla and its extensions, uses the GPL and this, of course, does not impact it.

It wasn't just Freedom, but also Collaboration and usability that I was pointing to. Given that I had forgotten about the 'Free, unlimited licence' Jira is offering.

However I still cannot see a good reason to use Github and another solution to manage issues, project, jobs, ideas, etc.

When the existing contribution process was created Git and Github did not exist, and so the process was designed around the tools available at that time. Now we have, and are using, Github the process to contribute should be redesigned based on the tool(s) avaialble now - and keep the barrier to entry as low as possible. To me, this means keeping things simple, and Git does that - and Github further enables collaboration on a global scale.

Project management tools are good for top-down driven development environments - and I have used them in the past to great effect - but in a community where the thing that gets done is the thing the developer is interested in (and they have the time to do it), as opposed to what the project leader says they must do (and when it mus be done by), then I see it being more of a hinderance than a help. A tool to beat people up with, if you will.

Lets face it, the Linux kernel is a pretty big project with a large collaboration team across the world and they use Git - so it is by no means difficult to manage large distributed projects with Git / Github (although Linus _hates_ github pull requests).

 

Just my thoughts :-)

Chris.

[kisswebdesign]

Thanks Michael,

On Thursday, February 28, 2013 2:15:24 PM UTC, Michael Babker wrote:

On Thursday, 28 February 2013 06:49:57 UTC-6, kisswebdesign wrote:

Goal #1: Complete Three Iterations of the Joomla Platform Project.

OK, 3 versions this year. Who will consume these versions?

I am unsure of who these releases are for. Which version is being targeted for use by the CMS, for example

Just a note here that the goals were written and defined prior to the Framework being implemented and that path being taken, as noted by Andrew elsewhere.

Yep, got that :-)

 

As for which version the CMS will use, the goal is to update the CMS to the latest Platform version with each release, with some exceptions.  Whatever Platform code was in CMS 3.0 when it was released will remain until 4.0 per the CMS deprecation strategy (only major releases allow backwards compatibility breaks, such as removing code).  So, code removed from the Platform has to be kept in the CMS files, meaning it isn't just a simple copy/paste between repos.  As well, we customized many of the JHtml classes while working on the Bootstrap integration, so that's another area that requires a bit more focus.  Lastly, we don't just merge the Platform in blindly, but typically will do patches following the Bug Squad workflow to get us in sync (sometimes, folks will port over small features as they need them, and as we get closer to release, we'll do bigger patches porting over more of the Platform code to get in sync).  This will become less of a concern as the Platform is officially reintegrated into the CMS, at which point the discussion should shift to how we can integrate pieces of the new Framework into the CMS.  But, that discussion should be saved for another thread down the road.

Thanks, didn't quite get this bit until now - great summary for me.

 

 

2.2 Enforce Joomla Coding Standards in All CMS Files

Why have coding standards if they are not followed. Of course bringing legacy code into line just for the sake of it (ie it adds no real value) is not something I would prioritise.

If a file is being worked on (bug fix, security, feature add, etc) then the whole file should be bought into line at that time.

A few people who commit to the CMS are doing just that, and at the same time, we work on larger changes to break some of the codestyle exceptions that can be committed without test.  A recent one was enforcing that all classnames are declared with a leading capital letter, something that all the plugins (i.e. plgSystemDebug) didn't do, and a change we could make without going through the workflow for testing.  Also, we don't want to make these changes in large batches so that our update packages aren't needlessly large with modified files that only changed due to codestyle, so those types of efforts are usually saved for the beginning of the year when we have to change the copyright in every file's header and near a major or minor release.  In the weeks leading into CMS 3.1, this would be a good time to work on improving the enforcement of codestyle rules.

 

Sounds like common sense is winning this one. I just didn't have any visibility on it, just the goal on the list.

 

Just my thoughts / feedback

Chris.

Thanks for the feedback! 

Anytime, just need to get one of the 'time turner' http://harrypotter.wikia.com/wiki/Time-Turner from Harry Potter then I would be able to do more than comment and do an occasional (tiny) pull request! 

[Andrea Tarr at Tarr Consulting]

Linux uses github for the repository but has its own processes outside where it determines that github isn't appropriate for the situation. See https://github.com/torvalds/linux/pull/17 for a very interesting read.

The tracking process in github doesn't work well for what we need to do with the bug squad. It's been detailed a few times what it is that we need that github can't handle including our workflows. Github is great, but it's not  one-stop shopping right out of the box, as much as we wish it were.

Andy

--

Andrea Tarr

[Matt Thomas]

As a follow-up, anyone who wants to help make the new tracker better, can. Please join us at https://github.com/JTracker/jissues.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[kisswebdesign]

Thanks Andy, I don't know much about the bug squad workflow - I will see if I can find some documentation about it (or you could send me a link or two to help, hint hint)

As I said about the Linux Kernel, they use Git (not Github) for managing the project. Mainly because Linus has strong opinions on Github pull requests (and pretty much everything else, lol) as I also said - but they still use Git for everything (accepting pull requests, patches, etc. using Git on their local machines) and pushing the resulting commit to github.

I know Github is not a one-box solution for everything, but I do think that the workflow and the tool are intrinsically linked so if one changes then the other should be re-examined. Don't define a fixed workflow and then try to fit it to a tool (or suite of tools), in the same way that the tool should not be fixed and then try to crowbar a workflow around it - the two need to fit together.

A process, or workflow, can become so familiar to those using it that it is hard to see if there are other (sometimes better) ways of working. Sometimes outside input is needed in order to see another way of doing things - I have worked in places where 'we've always done it like that' has ruled and driven the selection of tools, and others where the tool has been bought without consulting those who will use it and have it forced on people. Neither one is particularly useful.

Perhaps Github is not the tool for Joomla, and another tool can provide a single point for collaboration - my point is lets keep it as simple as possible, and use one tool instead of many. If that is not Github, then fine, I am not 'stuck' on using Github - but I do think it is the best tool for hosting projects at this moment in time.

Also, as I am not part of the bug squad I cannot see the workflow in action personally - so I am not going to try and tell you (or anyone else) how to do something that they are already doing. However, I will offer suggestions, thoughts and questions in order to help me (and maybe others) understand things.

I see the Github as great tool that could do so much more for a project than just hosting it. The Github issue tracker is really flexible, for example using 'labels' to identify category (feature, bug, etc) and/or priority (for something urgent) and status (reviewed, wip, invalid, etc) - and rolling-up a set of issues into a 'milestone' - assigning a collaborator - and so on.

Here is a link to an old github blog about issue management (in case you are interested)... https://github.com/blog/831-issues-2-0-the-next-generation

I really do feel that the whole project should use the same tool for managing issues, changes and source code, having different tools for different sections of a project just makes it harder for someone new to contribute - the last thing anyone wants is to stop people from helping.

Chris.

[Nick Savov]

Hi Chris,

Thanks for the great feedback! :) It helps a lot!

Kind regards,
Nick

[Andrea Tarr at Tarr Consulting]

We can go round and round about it. All I'm saying is that github as it stands doesn't work for that tracker. The process and the workflow and the needs have all been examined to come to that conclusion along with several different proposed solutions.  What we have ultimately come down to you can check out at Matt's link:  https://github.com/JTracker/jissues.

Thanks!

Andy

--

Andrea Tarr

[Michael Babker]

The goal with the new tracker is to inject data from GitHub directly into it, while allowing those not using GitHub but contributing to continue doing so.  So, theoretically, one could use GitHub and never see the tracker.  You can see the current state of the code in action at http://tracker.babdev.com where I have the CMS GitHub repo feeding data into it via the webhooks API.

To me, GitHub's issues tracker is a good to-do list and good for small projects which don't have defined workflows with varying permissions levels.  With our Bug Squad structure, GitHub is too simple and doesn't satisfy the Bug Squad and PLT requirements.

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

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[kisswebdesign]

Thanks Andy, Matt and Michael,

Didn't want to open old conversations, or stir anyone up, just putting my point of view.

I have cloned the jissues tracker (actually did it a couple of months ago) and have it running locally - with all the good intentions to contribute to it - time being what it is (ie linear and forward moving) I have not been able to spend much time looking at it. Although I still hope to do so, when the Time Turner gets delivered from Diagon alley (Time Turner info)

I hope no-one takes anything I say personally, or gets offended, annoyed or otherwise upset - I never set out to do that - but good intentions are no guarantee of outcome.

Kind regards,

Chris.

[Andrea Tarr at Tarr Consulting]

I think we are all trying to come up with the best, workable solutions :)

Andy

--

Andrea Tarr

[Michael Babker]

No issue or offense taken here.  Always glad to discuss the logic behind a decision so it's clear to everyone.  I'd be offended if people came around saying we weren't having these discussions in the open; I know there's a couple of long threads on I think the JBS group discussing tracker needs, and I've made it a point to keep all the tracker discussion open (code on GitHub, Google Group, and no Skype chat).

On Thursday, February 28, 2013, kisswebdesign wrote:

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

[Naouak]

Talking about contribs, here is my personal experience :

I've never created an account to joomla code. To see, to post, to use joomlacode, you need an account. I just don't want it to report a bug because reporting a bug is "me helping the project", not "me having to help the project".

I use regularly github; clone, fork, copy a lot of stuff from it and occasionally when I see something that seems not accurate, try to modify it and then do a pull request. Mosto f the time when I do a pull request it's for a project/code I don't really care about and I don't really care about if it is integrated or not. I'm just offering some help because I happen to look at that stuff.

I did several pull request to Joomla Platform and CMS. To platform I did a quite long chunk of code. I added tests for it and I changed all my IDE configuration just so that your bot doesn't tell me there is too much space or not enough.

I started a thread about it and proposed my solution. There was a discussion about it and I contributed to the discussion bringing my solution. The discussion moved to the pull request then it died.

9 Months later, I got someone telling me "It's not mergable".

Now with the cms.

I did also several pull request. These are more simple. I did one that just change a file to avoir some hardcode.

1 year later, I got a notification telling me : "you have to fill a bug on joomlacode". That's simply ridiculous.

I have a second one that I opened yesterday. My commit is just changing a number and I explain briefly why. This doesn't breack backward compatibility. I'm waiting for someone to tell me in 9 months that my code is either unmergable or is not part of a bug report.

My point is :

Most of the helpful contributions are from developpers that just happen to see that code and patch it.

I don't want to read a full page, sign some stuff, print it send it to some organization in the USA, fill a bug or anything like that to help you. 

I'm just offering you a solution to your problems, I don't really care about your process.

Sure if you start to contribute a lot, you will start to look into that agreement, the licence or even the process but not when you just want to do just a small contribution.

"I have this patch for them, let's post a bug report on their own bug tracker, then check their syntax style before doing a pull request." - said no one, ever.

Naouak, Grade 2 de Kobal.
Site web: http://www.naouak.net

[Nick Savov]

Hi Naouak,

Thanks for sharing your feedback and experience! Because many developers
use github, that's one reason that the new tracker project (which has
github integration) got started. Michael and his team are doing a great
job and I'm sure that once it's done, it will help developers such as
yourself.

Unfortunately/fortunately, process is important, and it's one major reason
that Joomla's stability is quite good. Sure, the process might not work
the best for you and your situation, but it works well for us and that's
why we use it. As with anything this big, there's generally plenty of
things that can be improved and we're working on improving certain
aspects.

Hope this helps!

Kind regards,
Nick

>> *--*
>> *Andrea Tarr*

>>
>>
>>
>>
>>
>>
>> On Feb 28, 2013, at 4:01 PM, kisswebdesign <
>> chris.jo...@kisswebdesign.co.uk> wrote:
>>
>> Thanks Andy, Matt and Michael,
>>
>> Didn't want to open old conversations, or stir anyone up, just putting
>> my
>> point of view.
>>
>> I have cloned the jissues tracker (actually did it a couple of months
>> ago)
>> and have it running locally - with all the good intentions to contribute
>> to
>> it - time being what it is (ie linear and forward moving) I have not
>> been
>> able to spend much time looking at it. Although I still hope to do so,
>> when
>> the Time Turner gets delivered from Diagon alley (Time Turner

>> info<http://harrypotter.wikia.com/wiki/Time-Turner>
>> )

[Andrew Eddie]

On Thursday, 28 February 2013 22:49:57 UTC+10, kisswebdesign wrote:

Goal #1: Complete Three Iterations of the Joomla Platform Project.

OK, 3 versions this year. Who will consume these versions?

I am unsure of who these releases are for. Which version is being targeted for use by the CMS, for example

The practice is to just tag the platform just to draw a line in the sand. This goal is more or less on hold as we've since initiated the Framework project. The Framework will use Semver so we don't get into this problem of having what are effectively just "snapshot" tags.

 

Also, Jira is a closed source, proprietary, 

So is the Mac on which I write the Open Source software, and so is Github for that matter. We don't have a stance on the tools anyone uses and any tools the project chooses should be free, as in free beer, for the community to use - that's all we worry about. We respect people have differing views on being 100% FOSS, and that's ok, but it's not a debate we want to be drawn into.

Regards,

Andrew Eddie

[Andrew Eddie]

On Friday, 1 March 2013 07:59:08 UTC+10, Naouak wrote:

I did several pull request to Joomla Platform and CMS. To platform I did a quite long chunk of code. I added tests for it and I changed all my IDE configuration just so that your bot doesn't tell me there is too much space or not enough.

I started a thread about it and proposed my solution. There was a discussion about it and I contributed to the discussion bringing my solution. The discussion moved to the pull request then it died.

9 Months later, I got someone telling me "It's not mergable".

We are going to try hard to work out how we can reduce this sort of problem. Reconfiguring the framework is going to help but I'm also open to ideas about how to keep the code quality high, but not take so long to review code. Part of the problem is that a lot of the time all review is left up to the maintainers and we just can't be expected to do it all. Sometime pull requests just fall through the cracks. We will probably put out a call for people interested in becoming maintainers but I think that only addresses part of the problem. 

Another aspect is that Github's pull request system isn't quite as flexible as we'd like, so anyone that can give Michael a hand with the new tracker would be appreciated as I think this would help the community see where they can chip in and help move code contributions forward (I wish I could find the time myself). We could use Jira's workflow for that, but I think for day-to-day contributions, that would scare a lot of people off.

I'm not sure what the perfect solution is - I'm open to suggestions as always.

Regards,

Andrew Eddie

[Michael Babker]

Since the tracker's come up a few times, as I mentioned before, there's a live instance at http://tracker.babdev.com and right now it is only serving as a test bed to ensure the GitHub integration is working properly.  Issue and pull request activity is fed to that instance and processed into the database.  It's doing that for both the CMS and the tracker project repos as a method to demonstrate how we could use it for multiple repos.

As for user interaction, we've ported the CMS's com_users over and updated it to the new MVC structure.  Because it is mostly self contained code or extending the legacy models (some of that functionality we've brought in additionally), that conversion effort went smoothly.  We also have the login and registration mechanisms in place, so users could actually register onto that live instance and use it.  There's quite a bit of functionality missing (one of the goals is to bring in the major features we use on Joomlacode), but there's enough present to actually use it and test what's already in place.

If you're interested in working on something, look at the Google Group (linked from the GitHub repo) and the issue tracker on GitHub.  Between those resources and the existing Joomlacode functionality, that should be a guideline on what needs to be completed.

My vision here is to embrace GitHub, use what makes it awesome, and add in the missing functionality we've indicated we want, and call it a day.  And I think we can do just that with a little bit of time and code.

--

[JM Simonet]

Honestly, opening an account on joomlacode is a piece of cake.

No one has to sign anything to get a joomlacode account...

It is there that bugsquad and other testing volunteers and bugs posters mostly work and there are many reasons for it as testers are not always developers.

Many of us, instead of going through all the shebang to produce PRs on github, just prefer to post .diff files on joomlacode and even, sometimes, to be sure to get testers, the full files to replace in order for non-git-aware people to test.

It has also the advantage to be able to see at first sigt when opening the .diff file in an editor what has been changed/added, instead of the double job which consists in adding .diff to the PR url on github, load the page, copy and paste in an editor.

Joomlacode also lets post easily screenshots and keeps things organised with the various status possible.

We can also compare various iterations of a patch when that patch evolves through the comments and proposals.

So, until we have a better solution, it's not a big deal to create a joomlacode tracker, add the link to the github PR for those that use PRs and add the tracker url in the PR comment.

Then comes the real issue: to get enough testers in a minimum time after a patch is proposed before it becomes obsolete. And for that aspect, using github directy or joomlacode has no impact.

"I have a second one that I opened yesterday. My commit is just changing a number and I explain briefly why. This doesn't breack backward compatibility. I'm waiting for someone to tell me in 9 months that my code is either unmergable or is not part of a bug report."

I replied to you on https://github.com/joomla/joomla-cms/pull/741 , but it may need a dicussion on joomlacode or even the cms list + using non deprecated code = should it be an exception and, as the string JERROR_ALERTNOAUTHOR is used for both 404 and 403 in core, shall it be changed elsewhere too?

Hope this helps considering the problem with a wider point of view.

JM

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 

[Naouak]

On Fri, Mar 1, 2013 at 8:11 AM, JM Simonet <infog...@gmail.com> wrote:

Honestly, opening an account on joomlacode is a piece of cake.

No one has to sign anything to get a joomlacode account...

It is there that bugsquad and other testing volunteers and bugs posters mostly work and there are many reasons for it as testers are not always developers.

I can say the same for github. Why don't these testers create an account on github and test issue reporting there ? You don't need to know a single line of code to use github's bug tracker.

Many of us, instead of going through all the shebang to produce PRs on github, just prefer to post .diff files on joomlacode and even, sometimes, to be sure to get testers, the full files to replace in order for non-git-aware people to test.

Again, for me it's the opposite. It's more easier to do a pull request on github that posting a diff file. It took me less than 2 minutes to do that pull request and the longest part was finding the file I wanted to patch. 

It has also the advantage to be able to see at first sigt when opening the .diff file in an editor what has been changed/added, instead of the double job which consists in adding .diff to the PR url on github, load the page, copy and paste in an editor.

In github, the diff is directly visible without having to open anything. 

 

Joomlacode also lets post easily screenshots and keeps things organised with the various status possible.

We can also compare various iterations of a patch when that patch evolves through the comments and proposals.

Github permit all that again. Without any problems. 

So, until we have a better solution, it's not a big deal to create a joomlacode tracker, add the link to the github PR for those that use PRs and add the tracker url in the PR comment.

Your better solution seems to be github to me.

If you don't use pull request systems in github, you are not really using github. Github is not just a free code repository, it's a social network. If you don't want the social part, don't use it. You don't use twitter to stock your action history.

 

Then comes the real issue: to get enough testers in a minimum time after a patch is proposed before it becomes obsolete. And for that aspect, using github directy or joomlacode has no impact.

"I have a second one that I opened yesterday. My commit is just changing a number and I explain briefly why. This doesn't breack backward compatibility. I'm waiting for someone to tell me in 9 months that my code is either unmergable or is not part of a bug report."

I replied to you on https://github.com/joomla/joomla-cms/pull/741 , but it may need a dicussion on joomlacode or even the cms list + using non deprecated code = should it be an exception and, as the string JERROR_ALERTNOAUTHOR is used for both 404 and 403 in core, shall it be changed elsewhere too?

Then again, as I explained earlier, I don't really care. I happened to see it there and patch it, if there is other place that have the same problem, you are now aware of it, you can take action.

Again, this is my opinion. Like I explained, I don't really care about 3.x as I won't migrate. 

Hope this helps considering the problem with a wider point of view.

JM

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 

--

[kisswebdesign]

Goal #1: Complete Three Iterations of the Joomla Platform Project.

The practice is to just tag the platform just to draw a line in the sand. This goal is more or less on hold as we've since initiated the Framework project. The Framework will use Semver so we don't get into this problem of having what are effectively just "snapshot" tags.
---
OK, thanks. I am watching the framework with much interest.
==========

Also, Jira is a closed source, proprietary,

--

So is the Mac on which I write the Open Source software, and so is Github for that matter. We don't have a stance on the tools anyone uses and any tools the project chooses should be free, as in free beer, for the community to use - that's all we worry about. We respect people have differing views on being 100% FOSS, and that's ok, but it's not a debate we want to be drawn into.

----
Fair enough, re: the free as in beer, I had forgotten that Jira was offering Joomla a free unlimited account. Which was my main point (with closed source and proprietary as additional points to go against it)
As for individuals using non FOSS tools, that is their choice (and they are free to make whatever choices they want), but when a decision is being made for a community, especially in the FOSS arena, I think the decisions need a bit more thought (regarding the community, the perception the choice has, and how it could reflect on the project) than individual personal decisions. Not that it would preclude using or not using any given tool, but that all ramifications had been examined and understood before the choice is made - eyes wide open.
I do prefer FOSS, and am passionate about it - but not fanatical, or refuse to use anything non FOSS. I do like github, for example, but really only use it because it runs git, and I run git myself.

Chris.

[Andrew Eddie]

On 1 March 2013 23:57, kisswebdesign <chris.jo...@kisswebdesign.co.uk> wrote:

Fair enough, re: the free as in beer, I had forgotten that Jira was offering Joomla a free unlimited account. 

Paying for services that we can pass on to the community for free is not out of the question, but free to us (the org.) is preferable. We take it case by case.

Regards,

Andrew Eddie

[elin]

In terms of production goals I would like to see you add "Maintain and ideally increase the amount of fun people have participating."

Elin

[Andrew Eddie]

On 2 March 2013 11:10, elin <elin....@gmail.com> wrote:

In terms of production goals I would like to see you add "Maintain and ideally increase the amount of fun people have participating."

I think the principle is fine, but any idea how we can measure success? :)

Regards,

Andrew Eddie 

[elin]

Oh ask a sociologist that and she'll tell you .. there are lots of ways starting with asking people who are actively contributing directly both open ended and quick close ended questions, do focus groups at major events, and lots of other ways including looking at chat logs in jbs and irc and other places people talk.

Elin

[Al Warren]

Speaking of fun. I do love digging through code. I can do it for hours. It's just the way my brain works. For me that's the fun part.

Of late I've taken to trying to give back a little in the forums. More recently, I've had to rethink that approach. Things haven't gone so well. Not that I would have expected it to considering most don't know me from Adam. And I think that's a valid point because that's the not so fun part. Some of us old farts who may have grown a bit snarky in our old age tend to ruffle the feathers of those who might wonder, "who is this idiot and where did he come from?" But that's beside the point and I seem to have digressed. So back on topic.

Digging through code - big fun.

Pull here push there. So so. Pull here, push there, post here, post there, post over at the other there, now go back and post a link, then return to the other there to post another link, now do the pull request. Whew. Not so fun.

And that's after trying to decypher the processes and procedures and which ones are current and which ones might have a cob web or too. So I step back and punt and hope I get it right. Again, not so fun.

Without going into too much history, I can remember a time, way back when, that being a part of an open source project was a real hoot. When things were really hopping. There was a great sense of commradere. A nice social atmosphere.

Elin makes a great point. Those of us who remember the great social interactions years ago will understand how important that is. For me, it's not quite the same anymore. Maybe I've just been away too long.

I don't know how to make it fun. I just know how important it is. Fun is good. Not fun is not good. That is all. 73