Idea storm for improving Joomla development
10 views
Skip to first unread message
Andrew Eddie
Dec 10, 2009, 12:31:32 PM12/10/09
to joomla-de...@googlegroups.com
This is a thread starter as a continuation of a conversation happening
on the forums that unfortunately got spoiled by a troll. See
http://forum.joomla.org/viewtopic.php?f=48&t=467238
on the forums that unfortunately got spoiled by a troll. See
http://forum.joomla.org/viewtopic.php?f=48&t=467238
Anyway, I'm sure most people have watch some or all of the streaming
video we captured from the Joomla Developers Conference in New York
last weekend (http://www.ustream.tv/jdc09). In particular we
introduced a new concept called Labs which is in the final stages of
preparation and addresses some of the logistical and infrastructure
issues that have made getting your hands dirty somewhat difficult.
If there is anything that you want to discuss about how we organise
development that has come out of the JDC or something else in general
related to that, share what's on your mind. Let's just have an
informal geek-to-geek chat about ideas and stuff relating to the job
of actually getting the core code written, tested and documented.
Don't be afraid to post silly or crazy ideas. Remember, it takes 1000
ideas to get 100 experiments to build 10 prototypes to yield 1
successful product :)
The floor is yours :)
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Robert
Dec 10, 2009, 12:50:29 PM12/10/09
to Joomla! General Development
Andrew,
could you give us a short overview about the Labs idea.
It it less fun to read this thread with 5 pages full of side
discussion, off topics and so on.
Furthermore the sound on the ustream/jcd09 was quite bad, also not fun
to follow the discussion.
Thanks in advance,
Robert
On 10 Dez., 18:31, Andrew Eddie <mambob...@gmail.com> wrote:
> This is a thread starter as a continuation of a conversation happening
> on the forums that unfortunately got spoiled by a troll. Seehttp://forum.joomla.org/viewtopic.php?f=48&t=467238
could you give us a short overview about the Labs idea.
It it less fun to read this thread with 5 pages full of side
discussion, off topics and so on.
Furthermore the sound on the ustream/jcd09 was quite bad, also not fun
to follow the discussion.
Thanks in advance,
Robert
On 10 Dez., 18:31, Andrew Eddie <mambob...@gmail.com> wrote:
> This is a thread starter as a continuation of a conversation happening
>
> Anyway, I'm sure most people have watch some or all of the streaming
> video we captured from the Joomla Developers Conference in New York
> last weekend (http://www.ustream.tv/jdc09). In particular we
> introduced a new concept called Labs which is in the final stages of
> preparation and addresses some of the logistical and infrastructure
> issues that have made getting your hands dirty somewhat difficult.
>
> If there is anything that you want to discuss about how we organise
> development that has come out of the JDC or something else in general
> related to that, share what's on your mind. Let's just have an
> informal geek-to-geek chat about ideas and stuff relating to the job
> of actually getting the core code written, tested and documented.
>
> Don't be afraid to post silly or crazy ideas. Remember, it takes 1000
> ideas to get 100 experiments to build 10 prototypes to yield 1
> successful product :)
>
> The floor is yours :)
>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer> Anyway, I'm sure most people have watch some or all of the streaming
> video we captured from the Joomla Developers Conference in New York
> last weekend (http://www.ustream.tv/jdc09). In particular we
> introduced a new concept called Labs which is in the final stages of
> preparation and addresses some of the logistical and infrastructure
> issues that have made getting your hands dirty somewhat difficult.
>
> If there is anything that you want to discuss about how we organise
> development that has come out of the JDC or something else in general
> related to that, share what's on your mind. Let's just have an
> informal geek-to-geek chat about ideas and stuff relating to the job
> of actually getting the core code written, tested and documented.
>
> Don't be afraid to post silly or crazy ideas. Remember, it takes 1000
> ideas to get 100 experiments to build 10 prototypes to yield 1
> successful product :)
>
> The floor is yours :)
>
> Regards,
Paladin
Dec 10, 2009, 1:30:58 PM12/10/09
to Joomla! General Development
OK, here's a thought, in very rough outline form:
Poll the users for suggestions for features they want to see added and
track the popularity of them. Keep the list compiled and public and
always open for additions. Do the same for independent extension devs.
Then get the dev team to create the list of features to be worked on.
The final list needs tempered by the fact we don't want to take all
the 3pd air away (it's the old principle of 'gleaning', we need to
leave space for independent devs to live in, if for no other reason
than they'll show us all sorts of ideas we haven't thought of) but we
also can't afford to ignore the majority of the customer base, which
are the site owners and implementors. Also, new features can be added
to the list at this point by devs, *if* the case can be made for them.
("I like it" is *not* making a case.)
I refuse to point this next remark at anyone in particular (and will
object strenuously if anyone else tries to point it) but I also need
to make an observation at this point. I've run several times into
comments along the lines of "You can't direct volunteers, you have to
let them work on what they want to work on." Anyone with that attitude
needs to shed it. I'm not writing unit tests because I love writing
unit tests; I'm writing them primarily because the project needs them
(desperately) and there's very few hands on that task. Joomla is
pointless and irrelevant if it doesn't deliver what the two sets of
customers (users/imtegrators and extension developers) want and need,
so we need to suck it up and do what *they* need to have done. If it's
also what we want to do, then great, it's a double win. if not, tough.
First priority should always be customers.(Yes, there are OS projects
that do only what they want, and not what their users want. Do *you*
use their software? I don't.)
Anyway, once the list is known, dev team should assign priorities,
based on overall roadmap (and don't be afraid to change the roadmap if/
when great but unanticipated features are requested -- the roadmap
should be living and changing, always adapting to the changing world
around it) popularity of feature, time required, etc. Then we start
grabbing pieces and implementing.
Maybe part of this is happening already. I don't know, I only know I
haven't seen it happening. And that brings me to the last bit of
advice I have for this process. Whatever decisions are made about the
final priority list, however they are made, make sure they're visible,
both the decisions *and* the reasoning behind them. It's instinctive
for humans to mistrust what they can't see. If the process is open,
then everyone can see what and why, and what they need to do to effect
changes if they don't agree with the result (and this will also lead
to better encounters in the forums -- since everything is in the open,
there's less room for speculation, and since the process itself is
open, if they want to change it, they know they need to show up for
the process).
Andrew Eddie
Dec 10, 2009, 1:59:30 PM12/10/09
to joomla-de...@googlegroups.com
Hi Robert
2009/12/10 Robert <rde...@googlemail.com>:
Currently the process for getting a branch sucks - no one will argue
with that. And there is a lot of confusion about what is expected.
For example, our release guidelines say that no new features go into
current releases (aka 1.5), yet we have a 1.5 Feature Patch tracker.
That's sending a horrible mixed message that we want features in 1.5,
yet the "rules" say they can't go in. I don't want people to labour
that point, but just want to acknowledge I know why some of you are
feeling frustrated. The system is broken - what can be done to fix
it.
So we'll be doing is moving the Joomla SVN to a dedicated server which
will get that off the heavily loaded JoomlaCode server. With several
exceptions, the SVN server will be completely open to anyone who has
an account. To get an account, you will simply need to register at
the developer.joomla.org site, agree to CLA (still being worked on)
and then you will have access to the whole repository.
The grande vision is to have the repo in four parts:
1. The Joomla Framework
2. The Joomla CMS
3. Incubator Projects
4. User playgrounds
All these areas are open with the exception of the Framework and CMS
trunks and releases (these have restricted commit access for obvious
reasons). All other areas are open to anyone and everyone.
So, working backwards.
4. User playgrounds
These are just personal spaces that you can use for your own work,
merge off other peoples work, or do whatever you like. You have your
own space but everyone else has access to write in there and you have
access to write in everyone else's personal space. It's sort of like
the docs wiki only with code (if you don't want people playing with
your code, that's what a JoomlaCode project is for). This is a place
to play with ideas that may end up in the Framework or the CMS one
day.
3. Incubator Projects
These are ideas that have gone beyond the "idea" stage and become
formal experiments, but are not yet ready to break out into, say, a
JoomlaCode project, or not yet ready to be included in the core. It
could include, for example, a developer tool suite, a pilot revision
control system, etc.
2. The Joomla CMS
This comprises a trunk and release branches which, as I said, are
controlled by trusted committers (no change to what is happening now
and no different from other significant OS projects). The difference
is that anyone will be able to cut one or more of their own branches
to do core work. In fact, all new work will have to be performed in
branches before committing to trunk. Trunk will only receive stable
patches, it won't be worked on directly.
As before though, everyone can work in any branch (except trunk and releases).
When people have a stable branch then there will be "some system" to
put it in a queue for evaluation. The PLT is still throwing ideas
around for how the first cut of that might look. Also, there will
probably be some guidance about what sort of patches (like a theme)
are desired for the "next" release. Please note, these are all fuzzy
ideas at the moment. You are welcome to throw in your own opinions.
The view is also to attempt to have a system which cuts the release
cycle from over 2 years to 6 months.
1. The Joomla Framework
Ultimately the Framework is going to be split off into it's own area
so that it can evolved independently of the CMS side of things. This
will give rise to "other" forms of applications that can be built on
the Framework. A simple example is a command line version of Joomla
(which are really cool to use).
That's it in a nut shell. It's a place which is easy to get into and
contribute to. The only prerequisite is that you know how to use SVN
and you are prepared to collaborate with other people in a courteous
and responsible way. If you don't, then JoomlaCode is there to use or
you can do your own thing.
Does that help frame what Labs is going to be about a little better?
We've tried to make it as open as possible while reducing the risk of
having complete anarchy in the released code areas.
I think the Dev conferences like we just had are going to play a more
important role in setting directions for the future versions as well
(compare with what Ubuntu does).
> It it less fun to read this thread with 5 pages full of side
> discussion, off topics and so on.
> Furthermore the sound on the ustream/jcd09 was quite bad, also not fun
> to follow the discussion.
Ok, we'll take that into account when we do them next year in various
places around the world.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/12/10 Robert <rde...@googlemail.com>:
>
> Andrew,
>
> could you give us a short overview about the Labs idea.
Sure.
> Andrew,
>
> could you give us a short overview about the Labs idea.
Currently the process for getting a branch sucks - no one will argue
with that. And there is a lot of confusion about what is expected.
For example, our release guidelines say that no new features go into
current releases (aka 1.5), yet we have a 1.5 Feature Patch tracker.
That's sending a horrible mixed message that we want features in 1.5,
yet the "rules" say they can't go in. I don't want people to labour
that point, but just want to acknowledge I know why some of you are
feeling frustrated. The system is broken - what can be done to fix
it.
So we'll be doing is moving the Joomla SVN to a dedicated server which
will get that off the heavily loaded JoomlaCode server. With several
exceptions, the SVN server will be completely open to anyone who has
an account. To get an account, you will simply need to register at
the developer.joomla.org site, agree to CLA (still being worked on)
and then you will have access to the whole repository.
The grande vision is to have the repo in four parts:
1. The Joomla Framework
2. The Joomla CMS
3. Incubator Projects
4. User playgrounds
All these areas are open with the exception of the Framework and CMS
trunks and releases (these have restricted commit access for obvious
reasons). All other areas are open to anyone and everyone.
So, working backwards.
4. User playgrounds
These are just personal spaces that you can use for your own work,
merge off other peoples work, or do whatever you like. You have your
own space but everyone else has access to write in there and you have
access to write in everyone else's personal space. It's sort of like
the docs wiki only with code (if you don't want people playing with
your code, that's what a JoomlaCode project is for). This is a place
to play with ideas that may end up in the Framework or the CMS one
day.
3. Incubator Projects
These are ideas that have gone beyond the "idea" stage and become
formal experiments, but are not yet ready to break out into, say, a
JoomlaCode project, or not yet ready to be included in the core. It
could include, for example, a developer tool suite, a pilot revision
control system, etc.
2. The Joomla CMS
This comprises a trunk and release branches which, as I said, are
controlled by trusted committers (no change to what is happening now
and no different from other significant OS projects). The difference
is that anyone will be able to cut one or more of their own branches
to do core work. In fact, all new work will have to be performed in
branches before committing to trunk. Trunk will only receive stable
patches, it won't be worked on directly.
As before though, everyone can work in any branch (except trunk and releases).
When people have a stable branch then there will be "some system" to
put it in a queue for evaluation. The PLT is still throwing ideas
around for how the first cut of that might look. Also, there will
probably be some guidance about what sort of patches (like a theme)
are desired for the "next" release. Please note, these are all fuzzy
ideas at the moment. You are welcome to throw in your own opinions.
The view is also to attempt to have a system which cuts the release
cycle from over 2 years to 6 months.
1. The Joomla Framework
Ultimately the Framework is going to be split off into it's own area
so that it can evolved independently of the CMS side of things. This
will give rise to "other" forms of applications that can be built on
the Framework. A simple example is a command line version of Joomla
(which are really cool to use).
That's it in a nut shell. It's a place which is easy to get into and
contribute to. The only prerequisite is that you know how to use SVN
and you are prepared to collaborate with other people in a courteous
and responsible way. If you don't, then JoomlaCode is there to use or
you can do your own thing.
Does that help frame what Labs is going to be about a little better?
We've tried to make it as open as possible while reducing the risk of
having complete anarchy in the released code areas.
I think the Dev conferences like we just had are going to play a more
important role in setting directions for the future versions as well
(compare with what Ubuntu does).
> It it less fun to read this thread with 5 pages full of side
> discussion, off topics and so on.
> Furthermore the sound on the ustream/jcd09 was quite bad, also not fun
> to follow the discussion.
places around the world.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Robert
Dec 11, 2009, 11:31:21 AM12/11/09
to Joomla! General Development
Thanks Andrew for the explanation.
That are many new possibilities to contribute and step in. Basicly I
think we haven't a problem with to less possibilities to help, but we
have a problem with attention. People contribute and (often) nobody
take the ball off and interact with the contirbutor. So people get the
feeling it is wasting time to contribute.
Form my point of view it is very important to have a clear process and
that people get a response if they participate.
On 10 Dez., 19:59, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Robert
>
> 2009/12/10 Robert <rde...@googlemail.com>:
>
>
>
> > Andrew,
>
> > could you give us a short overview about the Labs idea.
>
> Sure.
>
> Currently the process for getting a branch sucks - no one will argue
> with that. And there is a lot of confusion about what is expected.
> For example, our release guidelines say that no new features go into
> current releases (aka 1.5), yet we have a 1.5 Feature Patch tracker.
> That's sending a horrible mixed message that we want features in 1.5,
> yet the "rules" say they can't go in. I don't want people to labour
> that point, but just want to acknowledge I know why some of you are
> feeling frustrated. The system is broken - what can be done to fix
> it.
Thats a good example, 90% of the items there are totally untouched.
For me personally the first step were to disable the possibility to
create new items. If I know that there is something wrong then it
would not be better if I don't do anything.
Next step: Create a easy and documented process how feature request
will be handled in the future.
Next step: go through the old items and move the information to the
new process (much of work, but not doing that is ignoring the
contribution for people)
Robert
That are many new possibilities to contribute and step in. Basicly I
think we haven't a problem with to less possibilities to help, but we
have a problem with attention. People contribute and (often) nobody
take the ball off and interact with the contirbutor. So people get the
feeling it is wasting time to contribute.
Form my point of view it is very important to have a clear process and
that people get a response if they participate.
On 10 Dez., 19:59, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Robert
>
> 2009/12/10 Robert <rde...@googlemail.com>:
>
>
>
> > Andrew,
>
> > could you give us a short overview about the Labs idea.
>
> Sure.
>
> Currently the process for getting a branch sucks - no one will argue
> with that. And there is a lot of confusion about what is expected.
> For example, our release guidelines say that no new features go into
> current releases (aka 1.5), yet we have a 1.5 Feature Patch tracker.
> That's sending a horrible mixed message that we want features in 1.5,
> yet the "rules" say they can't go in. I don't want people to labour
> that point, but just want to acknowledge I know why some of you are
> feeling frustrated. The system is broken - what can be done to fix
> it.
For me personally the first step were to disable the possibility to
create new items. If I know that there is something wrong then it
would not be better if I don't do anything.
Next step: Create a easy and documented process how feature request
will be handled in the future.
Next step: go through the old items and move the information to the
new process (much of work, but not doing that is ignoring the
contribution for people)
Robert
Andrew Eddie
Dec 11, 2009, 11:44:13 AM12/11/09
to joomla-de...@googlegroups.com
Hi Robert
2009/12/11 Robert <rde...@googlemail.com>:
might look like?
Feature requests can just come on this list. I think we need to think
of a geeky name for them though. RFC is really boring. Then the
interested community can flog the idea to death and someone might
actually do the coding for it :)
> Next step: go through the old items and move the information to the
> new process (much of work, but not doing that is ignoring the
> contribution for people)
I don't think any of the existing patches will marry directly with
1.6. I'd ask people to see if the feature is still relevant and go
from there.
2009/12/11 Robert <rde...@googlemail.com>:
>
> Next step: Create a easy and documented process how feature request
> will be handled in the future.
Not feature requests, feature patches :) Any suggestions on what that
> Next step: Create a easy and documented process how feature request
> will be handled in the future.
might look like?
Feature requests can just come on this list. I think we need to think
of a geeky name for them though. RFC is really boring. Then the
interested community can flog the idea to death and someone might
actually do the coding for it :)
> Next step: go through the old items and move the information to the
> new process (much of work, but not doing that is ignoring the
> contribution for people)
1.6. I'd ask people to see if the feature is still relevant and go
from there.
Andrew Eddie
Dec 11, 2009, 12:03:00 PM12/11/09
to joomla-de...@googlegroups.com
Thanks Arlen.
There are some good points there.
2009/12/10 Paladin <arlen....@gmail.com>:
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
> To post to this group, send email to joomla-de...@googlegroups.com
> To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB
> -~----------~----~----~----~------~----~------~--~---
>
>
There are some good points there.
2009/12/10 Paladin <arlen....@gmail.com>:
> You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
> To post to this group, send email to joomla-de...@googlegroups.com
> To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB
> -~----------~----~----~----~------~----~------~--~---
>
>
Amy Stephen
Dec 11, 2009, 1:22:50 PM12/11/09
to joomla-de...@googlegroups.com
On Fri, Dec 11, 2009 at 10:44 AM, Andrew Eddie <mamb...@gmail.com> wrote:
> Next step: go through the old items and move the information to the
> new process (much of work, but not doing that is ignoring the
> contribution for people)
I don't think any of the existing patches will marry directly with
1.6. I'd ask people to see if the feature is still relevant and go
from there.
I created a Module for Joomla! 1.6 and added it as a feature patch. It was accepted by both Louis and Rob. Unfortunately, it sat for so long as a patch that it didn't apply any longer. I asked for interest on list, and rewrote it again after hearing it was still needed. However, it's sat there for a long time, again, and Modules in 1.6 have continued to evolve.
I'm not certain who is managing the release now, but if it's still needed, I will certainly update it once more, but if it's not needed, I would appreciate it if the issue was just closed so that I know.
Thanks.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
Andrew Eddie
Dec 11, 2009, 1:33:24 PM12/11/09
to joomla-de...@googlegroups.com
Hi Amy
Yep, I know it's there (I was actually referring to the 1.5 patch
tracker, but that's ok). The patches I am personally giving priority
to at the moment are for the Administrator (though, when the plugins
task I gave you are done, I will look at those as soon as I can).
Once it is Beta ready (and not a moving target) I'll be focussing on
the frontend in ernest. We still have some problems to solve with
regard to the nested categories and that will probably affect your
module. That's the best info I can give you at the moment.
2009/12/11 Amy Stephen <amyst...@gmail.com>:
Yep, I know it's there (I was actually referring to the 1.5 patch
tracker, but that's ok). The patches I am personally giving priority
to at the moment are for the Administrator (though, when the plugins
task I gave you are done, I will look at those as soon as I can).
Once it is Beta ready (and not a moving target) I'll be focussing on
the frontend in ernest. We still have some problems to solve with
regard to the nested categories and that will probably affect your
module. That's the best info I can give you at the moment.
2009/12/11 Amy Stephen <amyst...@gmail.com>:
michael pagler
Dec 12, 2009, 7:24:44 AM12/12/09
to joomla-de...@googlegroups.com
Hello Andrew,
maybe i missed soemthing (or being blind), but i cannot detect any registration at the developer site (only login und remembers).
Is it closed at the moment - or where to register?
thx
michael
maybe i missed soemthing (or being blind), but i cannot detect any registration at the developer site (only login und remembers).
Is it closed at the moment - or where to register?
thx
michael
2009/12/10 Andrew Eddie <mamb...@gmail.com>
Sam Moffatt
Dec 12, 2009, 8:13:14 AM12/12/09
to joomla-dev-general
ErikThe3rd
Dec 23, 2009, 3:14:33 PM12/23/09
to Joomla! General Development
For my component Communicator I introduced VotePoints for feature
request on JoomlaCode (http://joomlacode.org/gf/project/communicator/
tracker/?action=TrackerItemBrowse&tracker_id=8307). VotePoints will
be accumulated by donations via PayPal. The donation are used to pay
the support forum, and do not go into my pocket.
The idea was, the more VotePoint a feature request has, this feature
will be added into the next release.
request on JoomlaCode (http://joomlacode.org/gf/project/communicator/
tracker/?action=TrackerItemBrowse&tracker_id=8307). VotePoints will
be accumulated by donations via PayPal. The donation are used to pay
the support forum, and do not go into my pocket.
The idea was, the more VotePoint a feature request has, this feature
will be added into the next release.
However, it did not work out. But maybe someone can use this idea and
bring it forward.
Erik
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
e-builds
Dec 24, 2009, 6:12:42 AM12/24/09
to Joomla! General Development
I love your Votepoints idea, Erik. As a matter of fact, I have been
thinking the same idea for months now (though never done anything with
it).
It makes me think of another sort of wares, not freeware, but
featurepayware (or better).
In other words: You got my vote for this!
thinking the same idea for months now (though never done anything with
it).
It makes me think of another sort of wares, not freeware, but
featurepayware (or better).
In other words: You got my vote for this!
Though, I would not make it so strict. For example, allow donations
EXTRA votepoints, but everyone SOME votepoints.
Consider myself for example: I am a developer working 100% voluntary
for an NGO, I even made some joomla extensions, BUT I have just have
enough money to survive. I wouldn't think it fair if I wouldn't get
any votes.
Now that I am thinking this, what about different groups of votepoint
rights?
E.g.
Donators: 1 vote per $5
Main joomla developers: 20 votes
Outside Joomla-Developers: 5 votes (after at least x help on trackers)
Extension developers: 5 votes
Other joomla helpers (Manual writers, translaters, ...): 3 votes (+ 3
votes after at least x proven help)
Everyone else: 5 votes.
This is just an example, but the idea feels good while writing it.
Now, just for the record, I am ALL FOR ANY implentation of (better)
votes...
Cheers!
Reply all
Reply to author
Forward
0 new messages