Wilco and I have had a bit of an initial discussion and we'd like to propose the following:
1. ACL is accepted immediately - there is a branch ready and we can start discussing where we want to go and dig into the community comments we received.
2. Work on an update manager is accepted immediately - same for ACL, a branch is already created and we can start discussing the finer details of the goals.
3. We cut down the list by first removing any white paper that did not receive any community comments (doesn't mean they are a bad idea, and maybe it'll make it into a future version). There are about 27 of these.
4. We quickly scan the white paper forum for things that we think are not really for the Joomla! core (like things that are adequately serviced by 3pd's), or that are things we feel can wait until after 1.6 (eg, I would put NBS into this category). Just post what you think on list and we'll see where we have some common ground.
5. For those that remain (hopefully less than fifty), we try to squeeze them all in if at all possible. Most will be small things I should think. I'd like to have each white paper converted into a task on the tracker, and that task must outline what the goals and expected behaviour are. Some will no doubt be easier than others. We will likely have a single branch for most of the little things but if there is anything that looks like it needs a branch on it's own then we can assess that at the time. We'll also be looking at all up-skilling in the area of Unit Testing to give us yet another level of quality control.
Basically when a task is complete and there is a consensus that it's reached a reasonable level of quality and met the required goals, it will be merged back into the trunk (and then all branches will need to update off the trunk). In this way the trunk should be held in a very high state of readiness for when we next release. Time frame for 1.6 - not really set yet but a 3-4 month total cycle would be nice to aim for.
Could I have a quick show of hands on if you think #3 is acceptable, and also a list of the #4 items you think can wait. Once we've done that we can start writing up our first tasks and you can start getting into some fun stuff.
If there are any other questions, or if you have any issues with what's proposed don't be afraid to speak up.
Hi Andrew, as you expected, I'm against eliminating all requests without community response, since I think we could loose valuable proposals with this. (And it could be that some of my whitepapers didn't get a response... Don't want to have to eliminate them at the beginning. ;-) )
For #4: Everything that has something to do with blogging, since more or less all these proposals don't really state what they want to see in Joomla, multisite capability, multi-db support, requests for forum components, requests for tagging, SEO improvements (I'm going to be killed for this. Anyway...), microformats in core output, basically all new components that do not replace some kind of functionality in the current system.
In my eyes, we are trying to replace redundant functionality and code in this release, like the footer module, which I want to remove desperately, or com_massmail and com_messages, which I would replace with a single component. We don't want to add completely new sections of functionality, but fine-tune a lot of the stuff that we already have. Thats why a forum is completely out of the question for me, where a new com_messages driven by plugins or a module replacing most of the content modules, would be okay.
> Wilco and I have had a bit of an initial discussion and we'd like to > propose the following:
> 1. ACL is accepted immediately - there is a branch ready and we can > start discussing where we want to go and dig into the community > comments we received.
> 2. Work on an update manager is accepted immediately - same for ACL, a > branch is already created and we can start discussing the finer > details of the goals.
> 3. We cut down the list by first removing any white paper that did not > receive any community comments (doesn't mean they are a bad idea, and > maybe it'll make it into a future version). There are about 27 of > these.
> 4. We quickly scan the white paper forum for things that we think are > not really for the Joomla! core (like things that are adequately > serviced by 3pd's), or that are things we feel can wait until after > 1.6 (eg, I would put NBS into this category). Just post what you > think on list and we'll see where we have some common ground.
> 5. For those that remain (hopefully less than fifty), we try to > squeeze them all in if at all possible. Most will be small things I > should think. I'd like to have each white paper converted into a task > on the tracker, and that task must outline what the goals and expected > behaviour are. Some will no doubt be easier than others. We will > likely have a single branch for most of the little things but if there > is anything that looks like it needs a branch on it's own then we can > assess that at the time. We'll also be looking at all up-skilling in > the area of Unit Testing to give us yet another level of quality > control.
> Basically when a task is complete and there is a consensus that it's > reached a reasonable level of quality and met the required goals, it > will be merged back into the trunk (and then all branches will need to > update off the trunk). In this way the trunk should be held in a very > high state of readiness for when we next release. Time frame for 1.6 > - not really set yet but a 3-4 month total cycle would be nice to aim > for.
> Could I have a quick show of hands on if you think #3 is acceptable, > and also a list of the #4 items you think can wait. Once we've done > that we can start writing up our first tasks and you can start getting > into some fun stuff.
> If there are any other questions, or if you have any issues with > what's proposed don't be afraid to speak up.
On 01/04/2008, Hannes Papenberg <hackwa...@googlemail.com> wrote:
> Hi Andrew, > as you expected, I'm against eliminating all requests without community > response, since I think we could loose valuable proposals with this. > (And it could be that some of my whitepapers didn't get a response... > Don't want to have to eliminate them at the beginning. ;-) )
It's just a way to reduce the list. There are too many things to implement and I agree, there might be some good ideas, but all I'm suggesting is that paper with comments should get precedence. If we find that we actually get through all the other papers then, hey, let's attack these others.
> For #4: Everything that has something to do with blogging, since more or > less all these proposals don't really state what they want to see in > Joomla, multisite capability, multi-db support, requests for forum > components, requests for tagging, SEO improvements (I'm going to be > killed for this. Anyway...), microformats in core output, basically all > new components that do not replace some kind of functionality in the > current system.
Can you please list the actual papers you want to suggest to either defer or not do at all.
> In my eyes, we are trying to replace redundant functionality and code in > this release, like the footer module, which I want to remove > desperately, or com_massmail and com_messages, which I would replace > with a single component. We don't want to add completely new sections of > functionality, but fine-tune a lot of the stuff that we already have. > Thats why a forum is completely out of the question for me, where a new > com_messages driven by plugins or a module replacing most of the content > modules, would be okay.
Just remember that combining two components is a really big issue. Programmatically it's trivial and may make sense, but you then have to justify that to all the users that have to learn about the change, and you also have any printed material that becomes useless, docs, tutorials and the like to think about. Change management at the user level is a big issue. Modules, might be a different story (I'm all for adding a super-articles module), but given we want to bring in a lot of brand new functionality which people will have to learn, I don't think it wise to change other things (like com_massmail and com_messages) until we have to. They aren't perfect but neither are they particularly broken.
> > Wilco and I have had a bit of an initial discussion and we'd like to > > propose the following:
> > 1. ACL is accepted immediately - there is a branch ready and we can > > start discussing where we want to go and dig into the community > > comments we received.
> > 2. Work on an update manager is accepted immediately - same for ACL, a > > branch is already created and we can start discussing the finer > > details of the goals.
> > 3. We cut down the list by first removing any white paper that did not > > receive any community comments (doesn't mean they are a bad idea, and > > maybe it'll make it into a future version). There are about 27 of > > these.
> > 4. We quickly scan the white paper forum for things that we think are > > not really for the Joomla! core (like things that are adequately > > serviced by 3pd's), or that are things we feel can wait until after > > 1.6 (eg, I would put NBS into this category). Just post what you > > think on list and we'll see where we have some common ground.
> > 5. For those that remain (hopefully less than fifty), we try to > > squeeze them all in if at all possible. Most will be small things I > > should think. I'd like to have each white paper converted into a task > > on the tracker, and that task must outline what the goals and expected > > behaviour are. Some will no doubt be easier than others. We will > > likely have a single branch for most of the little things but if there > > is anything that looks like it needs a branch on it's own then we can > > assess that at the time. We'll also be looking at all up-skilling in > > the area of Unit Testing to give us yet another level of quality > > control.
> > Basically when a task is complete and there is a consensus that it's > > reached a reasonable level of quality and met the required goals, it > > will be merged back into the trunk (and then all branches will need to > > update off the trunk). In this way the trunk should be held in a very > > high state of readiness for when we next release. Time frame for 1.6 > > - not really set yet but a 3-4 month total cycle would be nice to aim > > for.
> > Could I have a quick show of hands on if you think #3 is acceptable, > > and also a list of the #4 items you think can wait. Once we've done > > that we can start writing up our first tasks and you can start getting > > into some fun stuff.
> > If there are any other questions, or if you have any issues with > > what's proposed don't be afraid to speak up.
Weeding out White Papers without comments isn't a fair standard - I remember the Q&T forum where legit issues were overshadowed and forgotten by noisy topics.
I'd say lets keep it simple. 1) Evaluation Round 1 - Filter out duplicate or unrelated posts. Move all white papers into Accepted, Rejected, or Under Consideration based on user feedback. Merge related topics. 2) Evaluation Round 2 - Move additional papers out of Under Consideration to either Accepted or Rejected based on user feedback. 3) Evaluation Round 3 - Move all remaining papers.
BTW, we could also create a category for Accepted for Later Revisions, meaning we're not going to do it now but we will do it later. This is a polite way of acknowledging the topic but being pragmatic about our objectives.
If we really wanted to do this democratically we could use a poll, but I'm hesitant to do this as every issue is VITAL to someone. The real question is, who is going to do the work.
> Could I have a quick show of hands on if you think #3 is acceptable, > and also a list of the #4 items you think can wait. Once we've done > that we can start writing up our first tasks and you can start getting > into some fun stuff.
Agreed, I might be a bit selfish here, since most of those requests are made by myself. Still. :-)
I have to disagree on your assumption that we can't change the UI. Joomla has been stable like that for 3 years now and we still have some usability issues, which just require certain changes in the system. This starts with removing or merging components where apropriate. I care for backwards compatibility and ease of use, but to deny a proposal because some books become outdated by this, is not an argument for me.
> On 01/04/2008, Hannes Papenberg <hackwa...@googlemail.com> wrote:
>> Hi Andrew, >> as you expected, I'm against eliminating all requests without community >> response, since I think we could loose valuable proposals with this. >> (And it could be that some of my whitepapers didn't get a response... >> Don't want to have to eliminate them at the beginning. ;-) )
> It's just a way to reduce the list. There are too many things to > implement and I agree, there might be some good ideas, but all I'm > suggesting is that paper with comments should get precedence. If we > find that we actually get through all the other papers then, hey, > let's attack these others.
>> For #4: Everything that has something to do with blogging, since more or >> less all these proposals don't really state what they want to see in >> Joomla, multisite capability, multi-db support, requests for forum >> components, requests for tagging, SEO improvements (I'm going to be >> killed for this. Anyway...), microformats in core output, basically all >> new components that do not replace some kind of functionality in the >> current system.
> Can you please list the actual papers you want to suggest to either > defer or not do at all.
>> In my eyes, we are trying to replace redundant functionality and code in >> this release, like the footer module, which I want to remove >> desperately, or com_massmail and com_messages, which I would replace >> with a single component. We don't want to add completely new sections of >> functionality, but fine-tune a lot of the stuff that we already have. >> Thats why a forum is completely out of the question for me, where a new >> com_messages driven by plugins or a module replacing most of the content >> modules, would be okay.
> Just remember that combining two components is a really big issue. > Programmatically it's trivial and may make sense, but you then have to > justify that to all the users that have to learn about the change, and > you also have any printed material that becomes useless, docs, > tutorials and the like to think about. Change management at the user > level is a big issue. Modules, might be a different story (I'm all > for adding a super-articles module), but given we want to bring in a > lot of brand new functionality which people will have to learn, I > don't think it wise to change other things (like com_massmail and > com_messages) until we have to. They aren't perfect but neither are > they particularly broken.
> Regards, > Andrew Eddie
>> Hannes
>> Andrew Eddie schrieb:
>>> Ok lady and gentleman, it's that time to start looking at these - the
>> > faster it gets done the faster we get coding :D
>> > Wilco and I have had a bit of an initial discussion and we'd like to >> > propose the following:
>> > 1. ACL is accepted immediately - there is a branch ready and we can >> > start discussing where we want to go and dig into the community >> > comments we received.
>> > 2. Work on an update manager is accepted immediately - same for ACL, a >> > branch is already created and we can start discussing the finer >> > details of the goals.
>> > 3. We cut down the list by first removing any white paper that did not >> > receive any community comments (doesn't mean they are a bad idea, and >> > maybe it'll make it into a future version). There are about 27 of >> > these.
>> > 4. We quickly scan the white paper forum for things that we think are >> > not really for the Joomla! core (like things that are adequately >> > serviced by 3pd's), or that are things we feel can wait until after >> > 1.6 (eg, I would put NBS into this category). Just post what you >> > think on list and we'll see where we have some common ground.
>> > 5. For those that remain (hopefully less than fifty), we try to >> > squeeze them all in if at all possible. Most will be small things I >> > should think. I'd like to have each white paper converted into a task >> > on the tracker, and that task must outline what the goals and expected >> > behaviour are. Some will no doubt be easier than others. We will >> > likely have a single branch for most of the little things but if there >> > is anything that looks like it needs a branch on it's own then we can >> > assess that at the time. We'll also be looking at all up-skilling in >> > the area of Unit Testing to give us yet another level of quality >> > control.
>> > Basically when a task is complete and there is a consensus that it's >> > reached a reasonable level of quality and met the required goals, it >> > will be merged back into the trunk (and then all branches will need to >> > update off the trunk). In this way the trunk should be held in a very >> > high state of readiness for when we next release. Time frame for 1.6 >> > - not really set yet but a 3-4 month total cycle would be nice to aim >> > for.
>> > Could I have a quick show of hands on if you think #3 is acceptable, >> > and also a list of the #4 items you think can wait. Once we've done >> > that we can start writing up our first tasks and you can start getting >> > into some fun stuff.
>> > If there are any other questions, or if you have any issues with >> > what's proposed don't be afraid to speak up.
Personally I don't agree with this decision, the rest of them I agree with. There was one or two I saw that could go into a later version as well.
Of all of the ones that you have suggested I only see one without your avatar (expose is handy in this case): http://forum.joomla.org/viewtopic.php?f=501&t=275054 (Joomla Update logic; RoscoHead) I agree with this, its in by default anyway +1
http://forum.joomla.org/viewtopic.php?f=501&t=265594 (JParam extensions; Hackwar) I think its a bit much for 1.6, maybe 1.7; we have enough going without altering something that will impact on other systems. JParam is already a rather heavy part of the system, I don't think complicating it even further at this point is a good idea. That said some of the ideas I like, though again, 1.7 perhaps. -1
http://forum.joomla.org/viewtopic.php?f=501&t=265664 (mod_content; Hackwar) It seems to bear a co-dependence on your JParam extensions, so whilst nice I think we need to leave this one alone for 1.6; additionally you don't denote the upgrade path to remove all of these things as well which would be a major change. -1
http://forum.joomla.org/viewtopic.php?f=501&t=265605 (Template params in DB; Hackwar) I wouldn't mind mind this, but I'm not fussed on it. Solves issues with rights issues for cases. I do worry that it adds yet another query to the db. 0
http://forum.joomla.org/viewtopic.php?f=501&t=276533 (Decoupling jos_users; Hackwar) I feel this is nice but again, the present system works fine for what we have, I'd much prefer a much larger solution to this problem than what you've done, which I feel needs to wait on ACL so that we can better manage these things; I'd put it on a 1.7 review pile. Additionally I don't think you've through the potential performance impacts that this may have as well. -0
http://forum.joomla.org/viewtopic.php?f=501&t=265906 (Media manager improvements; Hackwar) I like the idea but we've got a few projects for this for SoC, I'd like to see you mentor those projects if they get in rather than do this as a part of 1.6. -1
> Agreed, I might be a bit selfish here, since most of those requests are > made by myself. Still. :-)
> I have to disagree on your assumption that we can't change the UI. > Joomla has been stable like that for 3 years now and we still have some > usability issues, which just require certain changes in the system. This > starts with removing or merging components where apropriate. I care for > backwards compatibility and ease of use, but to deny a proposal because > some books become outdated by this, is not an argument for me.
> Hannes
> Andrew Eddie schrieb:
> > On 01/04/2008, Hannes Papenberg <hackwa...@googlemail.com> wrote:
> >> Hi Andrew, > >> as you expected, I'm against eliminating all requests without community > >> response, since I think we could loose valuable proposals with this. > >> (And it could be that some of my whitepapers didn't get a response... > >> Don't want to have to eliminate them at the beginning. ;-) )
> > It's just a way to reduce the list. There are too many things to > > implement and I agree, there might be some good ideas, but all I'm > > suggesting is that paper with comments should get precedence. If we > > find that we actually get through all the other papers then, hey, > > let's attack these others.
> >> For #4: Everything that has something to do with blogging, since more or > >> less all these proposals don't really state what they want to see in > >> Joomla, multisite capability, multi-db support, requests for forum > >> components, requests for tagging, SEO improvements (I'm going to be > >> killed for this. Anyway...), microformats in core output, basically all > >> new components that do not replace some kind of functionality in the > >> current system.
> > Can you please list the actual papers you want to suggest to either > > defer or not do at all.
> >> In my eyes, we are trying to replace redundant functionality and code in > >> this release, like the footer module, which I want to remove > >> desperately, or com_massmail and com_messages, which I would replace > >> with a single component. We don't want to add completely new sections of > >> functionality, but fine-tune a lot of the stuff that we already have. > >> Thats why a forum is completely out of the question for me, where a new > >> com_messages driven by plugins or a module replacing most of the content > >> modules, would be okay.
> > Just remember that combining two components is a really big issue. > > Programmatically it's trivial and may make sense, but you then have to > > justify that to all the users that have to learn about the change, and > > you also have any printed material that becomes useless, docs, > > tutorials and the like to think about. Change management at the user > > level is a big issue. Modules, might be a different story (I'm all > > for adding a super-articles module), but given we want to bring in a > > lot of brand new functionality which people will have to learn, I > > don't think it wise to change other things (like com_massmail and > > com_messages) until we have to. They aren't perfect but neither are > > they particularly broken.
> > Regards, > > Andrew Eddie
> >> Hannes
> >> Andrew Eddie schrieb:
> >>> Ok lady and gentleman, it's that time to start looking at these - the
> >> > faster it gets done the faster we get coding :D
> >> > Wilco and I have had a bit of an initial discussion and we'd like to > >> > propose the following:
> >> > 1. ACL is accepted immediately - there is a branch ready and we can > >> > start discussing where we want to go and dig into the community > >> > comments we received.
> >> > 2. Work on an update manager is accepted immediately - same for ACL, a > >> > branch is already created and we can start discussing the finer > >> > details of the goals.
> >> > 3. We cut down the list by first removing any white paper that did not > >> > receive any community comments (doesn't mean they are a bad idea, and > >> > maybe it'll make it into a future version). There are about 27 of > >> > these.
> >> > 4. We quickly scan the white paper forum for things that we think are > >> > not really for the Joomla! core (like things that are adequately > >> > serviced by 3pd's), or that are things we feel can wait until after > >> > 1.6 (eg, I would put NBS into this category). Just post what you > >> > think on list and we'll see where we have some common ground.
> >> > 5. For those that remain (hopefully less than fifty), we try to > >> > squeeze them all in if at all possible. Most will be small things I > >> > should think. I'd like to have each white paper converted into a task > >> > on the tracker, and that task must outline what the goals and expected > >> > behaviour are. Some will no doubt be easier than others. We will > >> > likely have a single branch for most of the little things but if there > >> > is anything that looks like it needs a branch on it's own then we can > >> > assess that at the time. We'll also be looking at all up-skilling in > >> > the area of Unit Testing to give us yet another level of quality > >> > control.
> Of all of the ones that you have suggested I only see one without your > avatar (expose is handy in this case):
Yes, I know, as I said, I'm a bit selfish. On the other hand, they solve a lot of the issues other whitepapers adress.
> http://forum.joomla.org/viewtopic.php?f=501&t=265594 (JParam > extensions; Hackwar) I think its a bit much for 1.6, maybe 1.7; we > have enough going without altering something that will impact on other > systems. JParam is already a rather heavy part of the system, I don't > think complicating it even further at this point is a good idea. That > said some of the ideas I like, though again, 1.7 perhaps. -1
I have (most of) this done in code already, ready to be patched into the core, without any backwards compatibility issues. The only problem that I still have is the JS to hide the table rows currently not active. Everything else works and does not seem to create a (serious) overhead. At the same time, its code that is only used when editing items, so in a normal site, this would rarely be called, but it would provide huge opportunities for 3PD.
> http://forum.joomla.org/viewtopic.php?f=501&t=265605 (Template params > in DB; Hackwar) I wouldn't mind mind this, but I'm not fussed on it. > Solves issues with rights issues for cases. I do worry that it adds > yet another query to the db. 0
I have the loading of the parameters done, too, and it does not add another query, since we have to load the template from the database anyway. instead it saves us loading another file, the params.ini in the template folder. The issue is more the template manager, but even that one is just a finger exercise. :-)
Its a simple change in com_config, got this one done, too and its a really quick fix.
> http://forum.joomla.org/viewtopic.php?f=501&t=276533 (Decoupling > jos_users; Hackwar) I feel this is nice but again, the present system > works fine for what we have, I'd much prefer a much larger solution to > this problem than what you've done, which I feel needs to wait on ACL > so that we can better manage these things; I'd put it on a 1.7 review > pile. Additionally I don't think you've through the potential > performance impacts that this may have as well. -0
I don't want to decouple this in 1.6 completely, but I'd like to start with it by using the author_alias field by default. It saves us a join on each page load. Its another simple fix, although I didn't code it yet.
> http://forum.joomla.org/viewtopic.php?f=501&t=265906 (Media manager > improvements; Hackwar) I like the idea but we've got a few projects > for this for SoC, I'd like to see you mentor those projects if they > get in rather than do this as a part of 1.6. -1
Got some code for this one, too. I wont be able to do the mentoring, since I have absolutely no time. In case we get a student doing this, I'd be happy to provide my code and we might move it to 1.7. If this one doesn't make it, I'd like to still do this in 1.6 We will still have some time and its again something, that can be coded in a relatively short time.
I'll try to compile a list of whitepapers with minor changes on the dutch Joomla day.
