[drupal-devel] Let's accept more interim solutions
I'm thinking we should give more room in Drupal to accepting and applying "interim" solutions: contributions that are clear improvements without necessarily addressing every conceivable objection. The high threshold we set for accepting changes has definite benefits--it keeps the code clean and functional. Yet, if the bar is too high, it also has significant costs. It discourages developers and wastes development time and expertise on repeated updating. And, equally importantly, it leaves problems unaddressed. I feel we need to give more weight to the question: what are the costs of doing nothing? Often, these are significant enough to justify implementing a partial or interim solution. Many problems don't lend themselves to full and immediate solution. Rather, building a solution is an iterative process. Applying more 'first steps' is a spur to the development process. It keeps developers engaged and builds momentum for fixing remaining details. In sum: let's be a bit less conservative, a bit more open to new ideas as they come in. There's nothing sacred about the code base. It's something we collectively build, fixing problems, opening new possibilities (complete with their own issues and problems), moving beyond the limitations of the inception while staying true to the founding goals and vision. Nedjo
Nedjo - I have long wanted our project to move in this direction. Thanks for expressing the idea so eloquently. Nedjo Rogers wrote:
I'm thinking we should give more room in Drupal to accepting and applying "interim" solutions: contributions that are clear improvements without necessarily addressing every conceivable objection.
The high threshold we set for accepting changes has definite benefits--it keeps the code clean and functional. Yet, if the bar is too high, it also has significant costs. It discourages developers and wastes development time and expertise on repeated updating. And, equally importantly, it leaves problems unaddressed.
I feel we need to give more weight to the question: what are the costs of doing nothing? Often, these are significant enough to justify implementing a partial or interim solution.
Many problems don't lend themselves to full and immediate solution. Rather, building a solution is an iterative process. Applying more 'first steps' is a spur to the development process. It keeps developers engaged and builds momentum for fixing remaining details.
In sum: let's be a bit less conservative, a bit more open to new ideas as they come in. There's nothing sacred about the code base. It's something we collectively build, fixing problems, opening new possibilities (complete with their own issues and problems), moving beyond the limitations of the inception while staying true to the founding goals and vision.
Nedjo
On 18 Apr 2005, at 20:43, Nedjo Rogers wrote:
In sum: let's be a bit less conservative, a bit more open to new ideas as they come in. There's nothing sacred about the code base. It's something we collectively build, fixing problems, opening new possibilities (complete with their own issues and problems), moving beyond the limitations of the inception while staying true to the founding goals and vision.
I'll try my best. Though bear in mind that we've been in a 1.5 month code freeze during which I didn't commit any significant improvements. -- Dries Buytaert :: http://www.buytaert.net/
In sum: let's be a bit less conservative, a bit more open to new ideas as they come in. There's nothing sacred about the code base. It's something we collectively build, fixing problems, opening new possibilities (complete with their own issues and problems), moving beyond the limitations of the inception while staying true to the founding goals and vision.
I'll try my best. Though bear in mind that we've been in a 1.5 month code freeze during which I didn't commit any significant improvements.
Yes, looking back on the past one and a half year since I am around, I have seen not much stable code accepted, and then refined. I still think that the "anytime CVS is stable enough" rule should be kept in mind. So some sacrifice in features might be desired, but stability should not be thrown off. Goba
Here is an example: my dependency patch. It works with the current codebase nicely. When Adrian's full-fledged install system hits the core, I will upgrade it, so it will handle module versions. But that's no reason to hold that patch until Adrian is ready. Regards Karoly Negyesi
A big -1 from me. Drupals core must be small, clean and most of all very stable. I beleive Drupal would benefit most from a linux alike idea: kernel and distro;s. A kernel (drupal core) is very conservative, vey well maintained and very strict in what it accepts. Its up to the distros to add modules, themes and pre-configured databases and ship that as their distro. And off course a distro could ship with patches applied to its particular core. For example a DrupalI18N would be a nice distro. But to allow "interim" solutions? naah. I think it will bring down our overall quality a lot. And it will make our porject a lot harder to maintain, since our CVS will be in a constant status of no--really-working. Much more than now. Bèr Op maandag 18 april 2005 20:43, schreef Nedjo Rogers:
I'm thinking we should give more room in Drupal to accepting and applying "interim" solutions: contributions that are clear improvements without necessarily addressing every conceivable objection.
The high threshold we set for accepting changes has definite benefits--it keeps the code clean and functional. Yet, if the bar is too high, it also has significant costs. It discourages developers and wastes development time and expertise on repeated updating. And, equally importantly, it leaves problems unaddressed.
I feel we need to give more weight to the question: what are the costs of doing nothing? Often, these are significant enough to justify implementing a partial or interim solution.
Many problems don't lend themselves to full and immediate solution. Rather, building a solution is an iterative process. Applying more 'first steps' is a spur to the development process. It keeps developers engaged and builds momentum for fixing remaining details.
In sum: let's be a bit less conservative, a bit more open to new ideas as they come in. There's nothing sacred about the code base. It's something we collectively build, fixing problems, opening new possibilities (complete with their own issues and problems), moving beyond the limitations of the inception while staying true to the founding goals and vision.
Nedjo Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Thursday 21 April 2005 09:28, Bèr Kessels wrote:
But to allow "interim" solutions? naah. I think it will bring down our overall quality a lot. And it will make our porject a lot harder to maintain, since our CVS will be in a constant status of no--really-working. Much more than now.
I've been reading both sides of this thread with interest, and after thinking about it, I'm mostly with Bèr on this issue. He expresses concerns that crossed my mind from the very first post on this thread. One of the best things about Drupal is that by the time a module makes it into the "Releases" page on drupal.org, it's ready for production use. If people want things on a faster schedule, the Sandbox system and the HEAD CVS branch are a great way to get your hands on early code. The drupal.org site has a better visibility into CVS (for non-technical people) than many other open source project sites, in my opinion. Kudos to the site designers for that! One possibility might be to create Project nodes on drupal.org earlier in the life cycle of a new module, and have a way for code that is still in a Sandbox to show up as a link from an associated Project, but on a page that's separate from the stable/released download pages. This would have the added benefit of helping contributed-module coders (like myself) recruit "alpha testers" earlier in the development cycle. Drupal's single greatest strength, IMO, is its well-thought-out architecture. Well-thought-out architectures don't often happen if interim solutions get adopted on a large scale. The problem is that the interim solution becomes the foundation for other interim solutions that rely on its code, and by the time someone gets around to really coding up the *right* solution, it's too late because of all the legacy code. (Here in the U.S., it's a running joke how many "temporary" Quonset huts built by the Army in WWII are still being used today. Friends of my family used to live in one, in fact.) One of Drupal's few weaknesses, IMO, is that for some modules the upgrade path is not clean. Often upgade-XYZ.php scripts are not thoroughly tested, in my experience, and also there is the problem with modules popping up for one Drupal version and then not being maintained going forward. Or they get merged into core (a good thing) but the data migration path is a little bumpy for non- technical site owners. Having more interim code in core might make this even worse, because core API changes are what makes contrib modules incompatible from release to release. I don't mean to be overly critical on this last point. If I didn't consider Drupal to be utterly fantastic in every way that matters, I wouldn't be here. But I think we have good, solid, stable core right now, and acceptably-stable contributed modules. To step back from that stability even a little would, in my opinion, be a mistake. Now, I also recognize the legitimate desire to not hold back good features forever. There's an old adage in buying hardware that says, "You can get a PC with infinite capacity and infinite speed for free, if you wait for infinite years." The same holds in software -- waiting for the "perfect" design vs. moving ahead with "good enough" is a balancing act, a compromise. As a good example of a compromise that works well, I would point to the recent inclusion of free-tagging vocabularies into core for 4.7. Most of us would agree that, while Morbus Iff's code is a great start, it doesn't include every possible feature that people could want. Some argue for user-specific free tags, some argue for automatic detection of similar tags. BUT...The existing patch is a good interim solution because it blends smoothly into the existing core architecture. Morbus Iff's patch provides a new UI for creating and editing terms, but the underlying taxonomy schema doesn't really change except for adding a boolean flag to each vocabulary to indicate that it allows free tags. This interim solution doesn't constrain us for the future. Thus, I would argue that a balance is the best policy, and probably one that is close to what we do now -- an evolutionary, rather than revolutionary, change, such as making early-stage projects more visible but not changing the speed of putting things into Drupal core. Kind regards, Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
On Thu, 21 Apr 2005, Syscrusher wrote:
On Thursday 21 April 2005 09:28, Bèr Kessels wrote:
But to allow "interim" solutions? naah. I think it will bring down our overall quality a lot. And it will make our porject a lot harder to maintain, since our CVS will be in a constant status of no--really-working. Much more than now.
I've been reading both sides of this thread with interest, and after thinking about it, I'm mostly with Bèr on this issue. He expresses concerns that crossed my mind from the very first post on this thread.
Yeah. Also, the examples given for what would constitute such interim solutions were not convincing to say the least. I still would like to see usefull patches hit core faster than they do now, though. I've no idea how this coul dbe achieved, though. Cheers, Gerhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Apr 2005, at 4:38 PM, Gerhard Killesreiter wrote:
I still would like to see usefull patches hit core faster than they do now, though. I've no idea how this coul dbe achieved, though.
That node revision patch's lifetime is just insane. If it were any other developer, they would probably have let it slide a long time ago. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCZ75mgegMqdGlkasRAtDwAJ9Nc2SfvmtACxCdhbSLfOCciWNQwwCgny21 iiSV8qC/IryxsoQs7q/NViw= =I7RO -----END PGP SIGNATURE-----
I still would like to see usefull patches hit core faster than they do now, though. I've no idea how this coul dbe achieved, though.
That node revision patch's lifetime is just insane. If it were any other developer, they would probably have let it slide a long time ago.
Sure, but if you were Dries, would you accept untested patches? I would not. Look how many people commented on the revisions patch. Not much. http://drupal.org/node/7582 Goba
On Thu, 21 Apr 2005, Gabor Hojtsy wrote:
I still would like to see usefull patches hit core faster than they do now, though. I've no idea how this coul dbe achieved, though.
That node revision patch's lifetime is just insane. If it were any other developer, they would probably have let it slide a long time ago.
Sure, but if you were Dries, would you accept untested patches? I would not. Look how many people commented on the revisions patch. Not much.
The reason that the patch was not applied is that I had it ready shortly after feature freeze. It also has quite a big impact on Drupal, so Dries decided to not apply it at that time. I think it was a good idea. I find it really difficult to get other developers interested in the patches I write. But then I am not particularly interested in pther people's patches. ;) Cheers, Gerhard
On Thu, 21 Apr 2005, Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 21 Apr 2005, at 4:38 PM, Gerhard Killesreiter wrote:
I still would like to see usefull patches hit core faster than they do now, though. I've no idea how this coul dbe achieved, though.
That node revision patch's lifetime is just insane.
See my explanation in my other mail. Another example could be this patch: http://drupal.org/node/4166 But again: It wasn't really a good patch and it considered quite a lot of bugs. To convine Dries that this is an important feature is another issue. ;)
If it were any other developer, they would probably have let it slide a long time ago.
Some things simply need to be done. Cheers, Gerhard
To clarify: ideally (and likely I'm just stating the obvious) the thresholds we set for acceptance reflect the stages of the development cycle. At the point we're currently at in the cycle - when the CVS HEAD has just been opened up after a new release - we should be working to clear away the backlog. This is the ideal time to be applying new patches: when we still have the rest of the cycle to work with. This means we have, probably, months to iron out any small remaining details, and also to take advantage of possibilities opened up by the changes. Or, if major unforeseen problems show up, to roll the change back--it wouldn't be the first time, and it's not the end of the world. If there's a time when we have maximum tolerance for small issues or instabilities in CVS, this would be it. As the cycle progresses, we have less time to work with, more need to be ensuring stability, and hence diminishing ability to apply large changes. In sum: early in the cycle - now! - is the time to be clearing the deck, applying any patch that has has obvious support, has addressed any major issues (leaving aside minor details or small remaining discussions) and applies without raising errors. Because if not now, then when?
To clarify: ideally (and likely I'm just stating the obvious) the thresholds we set for acceptance reflect the stages of the development cycle.
At the point we're currently at in the cycle - when the CVS HEAD has just been opened up after a new release - we should be working to clear away the backlog. This is the ideal time to be applying new patches: when we still have the rest of the cycle to work with. This means we have, probably, months to iron out any small remaining details, and also to take advantage of possibilities opened up by the changes. Or, if major unforeseen problems show up, to roll the change back--it wouldn't be the first time, and it's not the end of the world. If there's a time when we have maximum tolerance for small issues or instabilities in CVS, this would be it.
As the cycle progresses, we have less time to work with, more need to be ensuring stability, and hence diminishing ability to apply large changes.
In sum: early in the cycle - now! - is the time to be clearing the deck, applying any patch that has has obvious support, has addressed any major issues (leaving aside minor details or small remaining discussions) and applies without raising errors.
Who said this differently? It is just a matter of defining what constitutes "minor details". Goba
In sum: early in the cycle - now! - is the time to be clearing the deck, applying any patch that has has obvious support, has addressed any major issues (leaving aside minor details or small remaining discussions) and applies without raising errors.
Who said this differently? It is just a matter of defining what constitutes "minor details".
Goba
You're right, but arguing abstractly over what issues are "major" or "minor" is likely to lead nowhere fast. Likely we'd do better to focus on outcomes: what are we trying to achieve? I see the task as similar to getting ready for a release--we all work together on a common goal. For a release, it's identifying and fixing issues in the already-applied code. In this case - clearing the patch queue, getting many of those great changes and enhancements in - it's doing any remaining basic testing and fixing up of generally proven patches to make sure there aren't any glaring issues preventing application. We can judge by the question: did we clear the queue? A process might look like this: * We establish a goal: e.g., within two months of opening of HEAD, we apply or turn down 80 to 90 percent of patches that are two months or more old (and apply some promising newer ones as well). * At opening of HEAD, we (e.g., a set of volunteers) review the patch list and identify priority patches to be worked through quickly. * Patches from this list are applied if (a) one skilled developer (other than the primary submitter!) affirms successful testing and (b) a week has passed without new problems being identified. Obviously I'm just throwing these details out as ideas. As I write there are 107 core patches in the queue. This includes many that no longer apply, but by the same token some others that don't apply have been been reset to active (so the total list of patches outstanding is larger than 107). Of the subset that are promising, reasonably well reviewed, and have been more than two months in the queue: can we get most of them applied (or turned down) before they have to wait another whole development cycle?
Op donderdag 21 april 2005 18:00, schreef Nedjo Rogers:
In sum: early in the cycle - now! - is the time to be clearing the deck, applying any patch that has has obvious support, has addressed any major issues (leaving aside minor details or small remaining discussions) and applies without raising errors.
I did not get this idea from your first post. But if you put it this way, I tend to agree. My +1 was for lowering the treshold forr core patches in general. But if you put it like this: early in the cycle, apply big-impact patches, then use the rest for the cycle to iron out their effect on the core, i like the idea. But that is completely differnent from lowering the treshold; its just a slightly different approach in our method. In fact we need not lower any treshold, we only need to worry little less about all the effects of a big change. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
In sum: early in the cycle - now! - is the time to be clearing the deck, applying any patch that has has obvious support, has addressed any major issues (leaving aside minor details or small remaining discussions) and applies without raising errors.
I did not get this idea from your first post. But if you put it this way, I tend to agree. My +1 was for lowering the treshold forr core patches in general. But if you put it like this: early in the cycle, apply big-impact patches, then use the rest for the cycle to iron out their effect on the core, i like the idea.
But that is completely differnent from lowering the treshold; its just a slightly different approach in our method. In fact we need not lower any treshold, we only need to worry little less about all the effects of a big change.
Am I in a misunderstaing here, or we did this previously? I don't see the difference between the previous practice and the now cleaner proposal... Goba
On Thu, 21 Apr 2005 20:32:31 +0200, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
In sum: early in the cycle - now! - is the time to be clearing the deck, applying any patch that has has obvious support, has addressed any major issues (leaving aside minor details or small remaining discussions) and applies without raising errors. I did not get this idea from your first post. But if you put it this way, I tend to agree. My +1 was for lowering the treshold forr core patches in general. But if you put it like this: early in the cycle, apply big-impact patches, then use the rest for the cycle to iron out their effect on the core, i like the idea. But that is completely differnent from lowering the treshold; its just a slightly different approach in our method. In fact we need not lower any treshold, we only need to worry little less about all the effects of a big change.
Am I in a misunderstaing here, or we did this previously? I don't see the difference between the previous practice and the now cleaner proposal...
Neither do I. I've gotten the impression from Dries that the biggest roadblock right now is knowing whether a patch has been tested. He proposed some changes to project.module to make this information more clear. I say we code those changes and implement them on Drupal.org. After a couple months trying out the new system, we can talk about other improvements. -- Tim Altman
On Thu, 21 Apr 2005, [iso-8859-1] Bèr Kessels wrote:
Op donderdag 21 april 2005 18:00, schreef Nedjo Rogers:
In sum: early in the cycle - now! - is the time to be clearing the deck, applying any patch that has has obvious support, has addressed any major issues (leaving aside minor details or small remaining discussions) and applies without raising errors.
I did not get this idea from your first post. But if you put it this way, I tend to agree.
Yeah. But that sounds completely different from the proposal to accept "interim" solutions. Cheers, Gerhard
In sum: early in the cycle - now! - is the time to be clearing the deck,
I did not get this idea from your first post. But if you put it this way, I tend to agree.
Yeah. But that sounds completely different from the proposal to accept "interim" solutions.
I'm sorry if I've muddied the waters by addressing different ideas under the same discussion. I'll try to clarify. I believe I and others are making two related but distinct points: 1. In general, let's be a bit quicker to accept "interim" solutions--that is, to apply changes in stages. I don't see this in any way as lowering our standards. The aim, rather, is to speed up the development process, reducing (sometimes excessive and counterproductive) barriers to improvement of the code. Here's a common cycle in our current approach: * Problem or limitation is identified in existing code * Solution is proposed * Various objections are raised, but (often) no better solution proposed or coded * Time is spent over the course of several months addressing objections * Fresh objections are raised, some based on new changes elsewhere in the core * A new release comes out * Original identified problem remains, unaddressed This could have various possible outcomes: * Issue is eventually fixed * Contributor gives up, and stops submitting patches * Issue sits unaddressed until eventually someone else picks it up The cycle I'm suggesting is something like: * Problem or limitation is identified in existing code * Solution is proposed * Various issues are raised, and submitter (or others) codes responses * Patch is applied, remaining issues are noted * Further work is done to address remaining issues * Fresh patch is reviewed and applied I favour this approach particularly when the patch addresses an identified problem or deficiency in the existing core (as opposed to simply introducing brand new functionality). Does the proposal address a deficiency, is it an improvement on what we have, does it apply without raising bugs, and does it leave the door open to further refinements? Then, generally speaking, I want it in, whether or not it's been infinitely refined. That can come later. 2. Keeping (1) in mind, let's make a particular effort to clear the patch queue and apply improvements early in the development cycle. I'd say, in general, our current threshold is what I'd look for as we're nearing a code freeze (say, the last month). What I'm looking for is high standards but lower barriers in the rest of the cycle.
* Problem or limitation is identified in existing code * Solution is proposed * Various objections are raised, but (often) no better solution proposed or coded * Time is spent over the course of several months addressing objections * Fresh objections are raised, some based on new changes elsewhere in the core * A new release comes out * Original identified problem remains, unaddressed
So you would like to push an interim solution down into the throat of the community, so someone will eventually realize that the solution is not fine and will fix it. You think that pushing interim things into core will make refinements come faster? I think if there is no interest in refining some patch, there will possibly be no interest in going into fixing that stuff later on. Goba
So you would like to push an interim solution down into the throat of the community [etc.]
No one, I hope, is talking about pushing anything down anyone's throat. In this and other discussions, I've done my best to present proposals for change in a direct, constructive, and respectful way. It's about how we work together on a common goal. There are risks to putting thresholds too low, and I agree wholeheartedly with the concerns expressed. By just the same token, there are important risks to gatekeeping: presenting excessively high barriers to contribution. Either extreme threatens the quality of our project. My view of the record suggests we sometimes tend to the gatekeeping extreme. We could take some ameliorative steps, strike a more productive balance. I can't make the case any better than I have. "Drupal encourages users and developers to identify issues, welcomes innovative solutions from new and established contributors, and moves quickly to adopt high quality patches." That's what I'm aiming for. And I feel from comments that it's a widely shared goal.
It seems to me that a primary barrier to this goal is the intrinsic hackability of Drupal. Whereas a number of other systems (okay, I'm thinking of WordPress) expose a lot of "surface area" to relatively unskilled hackers to do cool and interesting things, Drupal's hackability is buried beneath a layer of complexity that makes it hard for folks like me who are interested in, but not capable of, making cool and exciting things happen. I don't have a clear idea of how to fix this, but I'm suggesting that we think about ways of pulling Drupal's cooler features up to the surface where making hacks are more accessible... one way to do this *might* be to offer module and theme editors in the admin section... making it possible to work on and improve modules without having to interact with a server... while many in the Drupal community might not be directly interested in this feature, I think it would do a great deal for bubbling up the ability to hack on do cool things with Drupal. Chris On 4/22/05, Nedjo Rogers <nedjo@gworks.ca> wrote:
"Drupal encourages users and developers to identify issues, welcomes innovative solutions from new and established contributors, and moves quickly to adopt high quality patches." That's what I'm aiming for. And I feel from comments that it's a widely shared goal.
On Mon, 25 Apr 2005, Chris Messina wrote:
It seems to me that a primary barrier to this goal is the intrinsic hackability of Drupal. Whereas a number of other systems (okay, I'm thinking of WordPress) expose a lot of "surface area" to relatively unskilled hackers to do cool and interesting things, Drupal's hackability is buried beneath a layer of complexity that makes it hard for folks like me who are interested in, but not capable of, making cool and exciting things happen.
I am inclined to say that this is a Good Thing(tm). You can make cool and exciting themes isn't that enough?
I don't have a clear idea of how to fix this, but I'm suggesting that we think about ways of pulling Drupal's cooler features up to the surface where making hacks are more accessible...
All the hooks are exposed to the outside and can be perused by modules. I don't see how you'd pull them more to the outside.
one way to do this *might* be to offer module and theme editors in the admin section... making it possible to work on and improve modules without having to interact with a server... while many in the Drupal community might not be directly interested in this feature,
Count me in. A lot of in-the-foot-shooting would be ensured. Programming isn't just for anybody. Do you have any idea how popular the theme_editor module is that you ship with CS?
I think it would do a great deal for bubbling up the ability to hack on do cool things with Drupal.
I think what you are after is some kind of macro language. Mathias had once created a metatags module. It had a sort of library of predefined functions accessible through tags that users could put into any node without being worried about breaking something. It was never very popular with developers (why bother of you can write php pages?) but might be just the thing you need. Cheers, Gerhard
On 25 Apr 2005, at 6:18 PM, Gerhard Killesreiter wrote:
On Mon, 25 Apr 2005, Chris Messina wrote:
It seems to me that a primary barrier to this goal is the intrinsic hackability of Drupal. Whereas a number of other systems (okay, I'm thinking of WordPress) expose a lot of "surface area" to relatively unskilled hackers to do cool and interesting things, Drupal's hackability is buried beneath a layer of complexity that makes it hard for folks like me who are interested in, but not capable of, making cool and exciting things happen.
I am inclined to say that this is a Good Thing(tm). You can make cool and exciting themes isn't that enough?
I don't have a clear idea of how to fix this, but I'm suggesting that we think about ways of pulling Drupal's cooler features up to the surface where making hacks are more accessible...
All the hooks are exposed to the outside and can be perused by modules. I don't see how you'd pull them more to the outside.
one way to do this *might* be to offer module and theme editors in the admin section... making it possible to work on and improve modules without having to interact with a server... while many in the Drupal community might not be directly interested in this feature,
Count me in. A lot of in-the-foot-shooting would be ensured. Programming isn't just for anybody.
Thinking by analogy with Unix, there's many more people who write interesting and useful shell scripts than there are C programmers. The power of being able to script things together avoids the need for a good number of programs, and a good deal of programming. So, programming may not be for everyone, but the right system design can let non-programmers do what they need, allows programmers great control over their code, and extends the reach of any given program to applications far beyond what the original scope might have been. (But yes, we do shoot ourselves in the foot sometimes, too :)
Do you have any idea how popular the theme_editor module is that you ship with CS?
I think it would do a great deal for bubbling up the ability to hack on do cool things with Drupal.
I think what you are after is some kind of macro language. Mathias had once created a metatags module. It had a sort of library of predefined functions accessible through tags that users could put into any node without being worried about breaking something. It was never very popular with developers (why bother of you can write php pages?) but might be just the thing you need.
Just what I was thinking. Something along the lines of Groovy or Beanshell for Java. Perhaps a JavaScript library giving access to Drupal components, state and services?
Cheers, Gerhard
-- Djun M. Kim, Director djun.kim@cielosystems.com Cielo Systems Inc. http://www.cielosystems.com Strategic Software Research Tel: (604) 739-3941 302 - 1298 10th Avenue West FAX: (604) 739-3943 Vancouver, BC, V6H 1J4 Mobile:(778) 895-1379
Thinking by analogy with Unix, there's many more people who write interesting and useful shell scripts than there are C programmers. The power of being able to script things together avoids the need for a good number of programs, and a good deal of programming.
So, programming may not be for everyone, but the right system design can let non-programmers do what they need, allows programmers great control over their code, and extends the reach of any given program to applications far beyond what the original scope might have been.
(But yes, we do shoot ourselves in the foot sometimes, too :)
Gotta agree with Djun. I wouldn't be able to use Linux/Unix without being able to "stitch" a few commands together and manipulate their output. Writing small script or composite command lines really helps to get things done quickly. Similarly, what would Apple be without Applescript? Here is a concrete example: Drupal blocks. Right now, we have a bunch of "per block visibility settings": 1. 'Show block on every page except ...' 2. 'Show block only on these pages ...' 3. 'Show block only on node pages of type ...' 4. 'Don't show this block when the throttle kicked in' While these offer a fair amount of control, more than once I bumped into the limitations of these "visibility rules". Concrete examples: 1. I wanted to create a block that is only visible to certain users. For example, I wanted to write a block that provides help to _new_ users. 2. I wanted to create a block that is only visible to certain user roles. 3. Various people want to display the 'book navigation' block on the main page. (This block is hardcoded only to show up when navigating a book.) 4. I wanted to create a block that is only visible on certain days or times of the year. (The 'Christmass Druplicon' block would be a good example. A 'Bugfix friday' block would be another example.) 5. I wanted to create a block that only shows up when the throttle kicked in (and not when the throttle is deactivated). To allow this kind of flexibility, we'd need to add various visibility settings. And even after we added these, it won't be possible to control how these rules interact. The current set of rules use implicit ANDs but maybe I want to use ORs or a combination of ANDs and ORs. The result? The block configuration page (1) becomes an "airplane cockpit" on its own and (2) even so, it can't take all possible configurations into account. The solution? Provide me a 70x8 textarea in which I can a write a block's "visbility check" using Drupal's APIs. Examples: 1. Only show block to 'authenticated users' that registered less than a month ago: return (time() - $user->created < x); 2. Only show block one week a year (eg. around Christmas): return (date('W') == 42); // only show block during week '42'. 3. Only show block to users with permission 'X': return user_access('X'); // I'm using a Drupal API here! ;-) 4. Only show block when looking at a forum topic: if (arg(0) == 'node' && is_numeric(arg(1)) { $node = node_load(array('nid' => arg(1))); // I'm using a Drupal API here! ;-) return ($node->type == 'forum'); } -- Dries Buytaert :: http://www.buytaert.net/
Gotta agree with Djun. I wouldn't be able to use Linux/Unix without being able to "stitch" a few commands together and manipulate their output. Writing small script or composite command lines really helps to get things done quickly. Similarly, what would Apple be without Applescript?
Problem is that if you break a shell script, there is no problem. If you break a Drupal module, then Drupal will completely break. It is like fiddling with the linux kernel (without having a backup to boot), not like writing a shell script. Goba
On 26 Apr 2005, at 12:12, Gabor Hojtsy wrote:
Gotta agree with Djun. I wouldn't be able to use Linux/Unix without being able to "stitch" a few commands together and manipulate their output. Writing small script or composite command lines really helps to get things done quickly. Similarly, what would Apple be without Applescript?
Problem is that if you break a shell script, there is no problem. If you break a Drupal module, then Drupal will completely break. It is like fiddling with the linux kernel (without having a backup to boot), not like writing a shell script.
I know but we already have PHP nodes/blocks and most of us can't without these. -- Dries Buytaert :: http://www.buytaert.net/
On Tue, 26 Apr 2005, Dries Buytaert wrote:
On 26 Apr 2005, at 12:12, Gabor Hojtsy wrote:
Gotta agree with Djun. I wouldn't be able to use Linux/Unix without being able to "stitch" a few commands together and manipulate their output. Writing small script or composite command lines really helps to get things done quickly. Similarly, what would Apple be without Applescript?
Problem is that if you break a shell script, there is no problem. If you break a Drupal module, then Drupal will completely break. It is like fiddling with the linux kernel (without having a backup to boot), not like writing a shell script.
I know but we already have PHP nodes/blocks and most of us can't without these.
PHP blocks are not for people that I'd describe as non-techs... This is rather what I'd recommend for the kind of people I am thinking about: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/macrotags/README.... Cheers, Gerhard
The solution? Provide me a 70x8 textarea in which I can a write a block's "visbility check" using Drupal's APIs.
I implemented your idea, as it is a) great idea b) very easy to do. There is one change which -- I think -- is not significant: you asked for a 70x8 textarea, but I have not changed the size, so it's a 70x5 textarea. After all, the codes you have provided as examples are not long. Otherwise, what was asked, is given. http://drupal.org/node/21353 Regards NK
I don't have a clear idea of how to fix this, but I'm suggesting that we think about ways of pulling Drupal's cooler features up to the surface where making hacks are more accessible... one way to do this *might* be to offer module and theme editors in the admin section... making it possible to work on and improve modules without having to interact with a server... while many in the Drupal community might not be directly interested in this feature, I think it would do a great deal for bubbling up the ability to hack on do cool things with Drupal.
And break the whole thing outright quite easily. If a single module is broken, then all you receive is a blank page, or even worse an error message. Goba
I'm terribly confused by what you mean... are you against this feature because it's "dangerous"? Perhaps we could provide better safeguards to prevent again "breaking the whole thing outright". I mean, if you don't like this idea, what kind of alternatives might you suggest? Chris On 4/26/05, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
I don't have a clear idea of how to fix this, but I'm suggesting that we think about ways of pulling Drupal's cooler features up to the surface where making hacks are more accessible... one way to do this *might* be to offer module and theme editors in the admin section... making it possible to work on and improve modules without having to interact with a server... while many in the Drupal community might not be directly interested in this feature, I think it would do a great deal for bubbling up the ability to hack on do cool things with Drupal.
And break the whole thing outright quite easily. If a single module is broken, then all you receive is a blank page, or even worse an error message.
Goba
On 26 Apr 2005, at 1:22 PM, Chris Messina wrote:
I'm terribly confused by what you mean... are you against this feature because it's "dangerous"?
Perhaps we could provide better safeguards to prevent again "breaking the whole thing outright".
I mean, if you don't like this idea, what kind of alternatives might you suggest?
Chris
On 4/26/05, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
I don't have a clear idea of how to fix this, but I'm suggesting that we think about ways of pulling Drupal's cooler features up to the surface where making hacks are more accessible... one way to do this *might* be to offer module and theme editors in the admin section... making it possible to work on and improve modules without having to interact with a server... while many in the Drupal community might not be directly interested in this feature, I think it would do a great deal for bubbling up the ability to hack on do cool things with Drupal.
And break the whole thing outright quite easily. If a single module is broken, then all you receive is a blank page, or even worse an error message.
Goba
Perhaps one could enable a 'test mode' in which settings would be checkpointed, and automatically rolled back by cron if changes are not manually committed? This might offer some protection. This approach might help new users recover from a bad attempt to enable 'clean URLs', also. Djun
I like this idea -- to a degree. Quicksilver on the Mac (blacktree.com) offers you three modes: Stable, Beta and Development, meaning that you can run at the bleeding edge if you're feeling brave or you can simply use the most stable code. Drupal could offer an administrative setting (perhaps in conf.php) that would enable experimental code for testing... I dunno, that does seem a bit out there, but it's a novel idea to address the concerns raised so far. Chris On 4/26/05, puregin <puregin@puregin.org> wrote:
On 26 Apr 2005, at 1:22 PM, Chris Messina wrote:
I'm terribly confused by what you mean... are you against this feature because it's "dangerous"?
Perhaps we could provide better safeguards to prevent again "breaking the whole thing outright".
I mean, if you don't like this idea, what kind of alternatives might you suggest?
Chris
On 4/26/05, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
I don't have a clear idea of how to fix this, but I'm suggesting that we think about ways of pulling Drupal's cooler features up to the surface where making hacks are more accessible... one way to do this *might* be to offer module and theme editors in the admin section... making it possible to work on and improve modules without having to interact with a server... while many in the Drupal community might not be directly interested in this feature, I think it would do a great deal for bubbling up the ability to hack on do cool things with Drupal.
And break the whole thing outright quite easily. If a single module is broken, then all you receive is a blank page, or even worse an error message.
Goba
Perhaps one could enable a 'test mode' in which settings would be checkpointed, and automatically rolled back by cron if changes are not manually committed? This might offer some protection. This approach might help new users recover from a bad attempt to enable 'clean URLs', also.
Djun
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The more i think about it. the more I like it. At the very least, it could completely take over all block assignment, and instead of having columns, use the current theme with textareas placed in each of the regions. Perhaps offering only a set of functions that we want them too, but then making sure the useable api is visible, and well documented. This could somewhat sandbox the users into what is available. Hell, perhaps even just have an [exec|exit();] Perhaps CCK could even use it as the the basis of the form designer. A text area, and an AJAX preview window that gets automatically refreshed. I think it has the potential to make drupal an incredibly expressive system. Each release has a pdf cheat sheet of the functions available for that specific versions. Do any other cms' have that kind of functionality ? - -`- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCcC75gegMqdGlkasRAqYIAJ0cvD7XlTxrEw84rvu73wGr+2xSbgCff5Jb aCOmCjmehU4qAroCKVebf2U= =hXRr -----END PGP SIGNATURE-----
I don't have a clear idea of how to fix this, but I'm suggesting that we think about ways of pulling Drupal's cooler features up to the surface where making hacks are more accessible... one way to do this *might* be to offer module and theme editors in the admin section... making it possible to work on and improve modules without having to interact with a server... while many in the Drupal community might not be directly interested in this feature, I think it would do a great deal for bubbling up the ability to hack on do cool things with Drupal.
And break the whole thing outright quite easily. If a single module is broken, then all you receive is a blank page, or even worse an error message.
Perhaps one could enable a 'test mode' in which settings would be checkpointed, and automatically rolled back by cron if changes are not manually committed? This might offer some protection. This approach might help new users recover from a bad attempt to enable 'clean URLs', also.
Cron will include all Drupal anyway, so if you have a broken edited module, then cron will be broken. Goba
This only works, if you provide a layer of parsing on top of the Drupal API. Look what bbcode does, to prevent you from doing HTML mistakes. If you made a bbcode mistake, it will show up in the output, but will not break the whole HTML page. If you provide a layer to protect Drupal from the user, the user will be safe. Otherwise, he will easily break the whole system, and will have a very hard time to recover (get to know that what is broken, remove broken code from database/file system, etc). But, providing a layer is not a simple task, if you are about to help people edit themes, or even modules as you suggested. Smarty is a layer of this kind, which shows you how complex it gets. Plus then the user needs to learn to use that syntax, instead of properly learning PHP, with hand editing stuff around the file system, which needs a bit more time in the first place, but then gives tremendously more power at the end. Goba
I'm terribly confused by what you mean... are you against this feature because it's "dangerous"?
Perhaps we could provide better safeguards to prevent again "breaking the whole thing outright".
I mean, if you don't like this idea, what kind of alternatives might you suggest?
And break the whole thing outright quite easily. If a single module is broken, then all you receive is a blank page, or even worse an error message.
Goba
To name a good counter example, consider the "book blocks as menu" patch. This patch addresses many issues. But it has one important one problem: you cannot set it up anymore so that a book block appears only on one of its pages (without setting up a gazillion block admin paths). I do not want this patch committed until that problem is addressed as it is very important for Drupal.org's handbook rewriting. Steven Wittens
But to allow "interim" solutions? naah. I think it will bring down our overall quality a lot. And it will make our porject a lot harder to maintain, since our CVS will be in a constant status of no--really-working. Much more than now.
I've been reading both sides of this thread with interest, and after thinking about it, I'm mostly with Bèr on this issue. He expresses concerns that crossed my mind from the very first post on this thread.
Yeah. Also, the examples given for what would constitute such interim solutions were not convincing to say the least.
I still would like to see usefull patches hit core faster than they do now, though. I've no idea how this coul dbe achieved, though.
It does not depend on those holding their hands on the core. It depends on those, who are only willing to test new stuff, if it is core already. Testing after applying a patch is definitely not how things go. The problem is that several good improvements are not tested widely. If more people would look around and check out improvements then great stuff would quickly get enough attention to be promoted to core and/or to the respective contrib module. Goba
I completely agree with Ber on this one. And I think we should go for a smaller core and then some distributions with pre-packaged modules and specific patches. And we should start separating concepts like 'Drupal core' and 'standard distribution'. Bèr Kessels wrote:
A big -1 from me. Drupals core must be small, clean and most of all very stable. I beleive Drupal would benefit most from a linux alike idea: kernel and distro;s. A kernel (drupal core) is very conservative, vey well maintained and very strict in what it accepts. Its up to the distros to add modules, themes and pre-configured databases and ship that as their distro. And off course a distro could ship with patches applied to its particular core. For example a DrupalI18N would be a nice distro.
But to allow "interim" solutions? naah. I think it will bring down our overall quality a lot. And it will make our porject a lot harder to maintain, since our CVS will be in a constant status of no--really-working. Much more than now.
Bèr
Regards, Bèr
I am in agreement with this line of thinking, but I also feel like the whole modules arena is getting to be wild territory. In the long run, perhaps it will make sense to have an "inner circle" of modules in addition to a clean and fast core. The collection of modules wouldn't necessarily be distributed with core, but represent an array of non-overlapping functionality. Pehaps this is achieved through votes or a certain level of maturity. It is just starting to get to the point where the module list is getting unwieldy and it isn't clear what each is doing, so there's overlap and inexperience. The tier of "approved" modules would presumably not suffer this problem, so if they do include patches to core it won't be as big of a concern. This lets core stay clean and efficient, diffuses some module confusion and - where appropriate - lets modules themselves provide interim solutions. On Friday, April 22, 2005, at 04:22 AM, Jose A. Reyero wrote:
I completely agree with Ber on this one.
And I think we should go for a smaller core and then some distributions with pre-packaged modules and specific patches. And we should start separating concepts like 'Drupal core' and 'standard distribution'.
Bèr Kessels wrote:
A big -1 from me. Drupals core must be small, clean and most of all very stable. I beleive Drupal would benefit most from a linux alike idea: kernel and distro;s. A kernel (drupal core) is very conservative, vey well maintained and very strict in what it accepts. Its up to the distros to add modules, themes and pre-configured databases and ship that as their distro. And off course a distro could ship with patches applied to its particular core. For example a DrupalI18N would be a nice distro.
Allie Micka pajunas interactive, inc. http://www.pajunas.com/ scalable web hosting and open source solutions
On Apr 22, 2005, at 2:14 PM, Allie Micka wrote:
The collection of modules wouldn't necessarily be distributed with core, but represent an array of non-overlapping functionality. Pehaps this is achieved through votes or a certain level of maturity. It is just starting to get to the point where the module list is getting unwieldy and it isn't clear what each is doing, so there's overlap and inexperience. The tier of "approved" modules would presumably not suffer this problem, so if they do include patches to core it won't be as big of a concern.
This starts to get off the "patch" topic in into the larger area of module management on drupal.org. It seems like Drupal's popularity is growing exponentially and so is module development. And with so many modules it's hard to tell what is what. Speaking as a person who only discovered Drupal about 5 months ago, it was really hard to figure out what were the *important* modules, which were essentially duplicates of other outdated modules, and so on. I've been thinking that it might be a good idea to enable some sort of comments for the module pages. Many developers post their module with only a line or two about what it does. Comments would allow users to post more information about the module, post links to other modules that have similar-but-different functionality, tips on how to use the module, etc. The comment system at php.net is essential for figuring out tips and tricks for PHP functions and it seems like we could have the same thing for modules. Another step in this direction would be a module rating system, but there are potential flaws with that - such as a high rated module that *used* to be essential, but now is obsolete. -Jeff Robbins jjeff
On Fri, 22 Apr 2005, Jeff Robbins wrote:
On Apr 22, 2005, at 2:14 PM, Allie Micka wrote:
The collection of modules wouldn't necessarily be distributed with core, but represent an array of non-overlapping functionality. Pehaps this is achieved through votes or a certain level of maturity. It is just starting to get to the point where the module list is getting unwieldy and it isn't clear what each is doing, so there's overlap and inexperience. The tier of "approved" modules would presumably not suffer this problem, so if they do include patches to core it won't be as big of a concern.
This starts to get off the "patch" topic in into the larger area of module management on drupal.org. It seems like Drupal's popularity is growing exponentially and so is module development. And with so many modules it's hard to tell what is what.
Right.
Speaking as a person who only discovered Drupal about 5 months ago, it was really hard to figure out what were the *important* modules, which were essentially duplicates of other outdated modules, and so on.
I've been thinking that it might be a good idea to enable some sort of comments for the module pages. Many developers post their module with only a line or two about what it does. Comments would allow users to post more information about the module, post links to other modules that have similar-but-different functionality, tips on how to use the module, etc. The comment system at php.net is essential for figuring out tips and tricks for PHP functions and it seems like we could have the same thing for modules.
I consider this to be in principle a good idea. The problem is that people will also post support requests there and that somebody would need to delete those and there should be a line informing people that such requests would be deleted. As long as we cannot give project owners the power to only delete comments on thier project nodes, this isn't really going to work.
Another step in this direction would be a module rating system, but there are potential flaws with that - such as a high rated module that *used* to be essential, but now is obsolete.
If module is really obsolete, it will be removed. The problem is that we currently offer downloads for at least the Drupal versions since 4.0 if not 3.0. We maybe should limit this to 4.4 to HEAD and remove all projects that do not have releases for any of those versions and which are not developed actively anymore. I am also very fond of the idea to categorize our modules through taxonomy. The problem is that Dries isn't sure that this would work well with project module. Project.module relies on taxonomy for some other stuff (themes, modules, ...) and adding another vocab might break that. Since Dries won't let me try it on drupal.org and I don't have a project.module install myself it would be helpfull if somebody would step forward and do some tests. Cheers, Gerhard
On Apr 23, 2005, at 5:53 AM, Gerhard Killesreiter wrote:
On Fri, 22 Apr 2005, Jeff Robbins wrote:
On Apr 22, 2005, at 2:14 PM, Allie Micka wrote:
The collection of modules wouldn't necessarily be distributed with core, but represent an array of non-overlapping functionality. Pehaps this is achieved through votes or a certain level of maturity. It is just starting to get to the point where the module list is getting unwieldy and it isn't clear what each is doing, so there's overlap and inexperience. The tier of "approved" modules would presumably not suffer this problem, so if they do include patches to core it won't be as big of a concern.
[stuff deleted]
I've been thinking that it might be a good idea to enable some sort of comments for the module pages. [snip] The comment system at php.net is essential for figuring out tips and tricks for PHP functions and it seems like we could have the same thing for modules.
I consider this to be in principle a good idea. The problem is that people will also post support requests there and that somebody would need to delete those and there should be a line informing people that such requests would be deleted. As long as we cannot give project owners the power to only delete comments on thier project nodes, this isn't really going to work.
Yes, well it should probably be moderated in one way or another. Maybe community moderation? And even PHP.net gets some support requests in the comments. But mostly it's a U.I. issue. If there's bold text at the top of the comment submit textarea saying "DO NOT POST SUPPORT REQUESTS HERE", there probably won't be too many. I guess I'm sort of thinking of this as a mini-book for each module, but less page-oriented and more list oriented (meaning all on one page). Where users could post tips and tricks and manual-page-type information; short one-liners or long tutorials. With so many of the modules defining complete API's (ecommerce, location, event, etc), I'm finding that I'm discovering new ways of using modules and perhaps others could benefit from experience. I could certainly post in the forums, but I doubt that new users are cross-referencing each module against the forums when they're trying to decide which modules to use.
Another step in this direction would be a module rating system, but there are potential flaws with that - such as a high rated module that *used* to be essential, but now is obsolete.
If module is really obsolete, it will be removed. The problem is that we currently offer downloads for at least the Drupal versions since 4.0 if not 3.0. We maybe should limit this to 4.4 to HEAD and remove all projects that do not have releases for any of those versions and which are not developed actively anymore.
Well this becomes another discussion, but what's one person's "obsolete" is another person's "stable version". Another issue with rating systems is that they are prone to politicking and I'd hate for a good module to be badly rated because its developer is not a good marketer. Or vice versa.
I am also very fond of the idea to categorize our modules through taxonomy. The problem is that Dries isn't sure that this would work well with project module. Project.module relies on taxonomy for some other stuff (themes, modules, ...) and adding another vocab might break that. Since Dries won't let me try it on drupal.org and I don't have a project.module install myself it would be helpfull if somebody would step forward and do some tests.
Taxonomy is good. And it might work to have someone who is the Module Moderator and could make decisions like which modules get tagged as: "Gold Star", "Important", "Obsolete", "Inactive", "API", "Headed for Core", "Piece of Crap", "Coded by Monkey", etc... And just for reference, Mambo features an entire website dedicated to its modules, components, and themes: http://mamboforge.net To be honest, I'm not sure that it's any better than what's going on at Drupal.org, but it's worth seeing what the "other guys" are doing. -Jeff
Jeff Robbins wrote:
And just for reference, Mambo features an entire website dedicated to its modules, components, and themes: http://mamboforge.net
I've noticed that site as well. I haven't dug into that site too deeply, but it creates the *impression* at least that (1) the Mambo community is large (larger than Drupal's community) and (2) there's room for all levels of module development and the status of each project is well understood. I find it fairly easy through SourceForge's interface (and by extension MamboForge and others like it) to figure out what's useful and what's crap (mostly by looking at a module's activity level and status). It's much harder in Drupal, despite the relatively small number of modules (as compared to SF projects!), to figure out what's useful. DrupalForge anyone? -Eric
On Sun, 24 Apr 2005, Eric Scouten wrote:
Jeff Robbins wrote:
And just for reference, Mambo features an entire website dedicated to its modules, components, and themes: http://mamboforge.net
I've noticed that site as well. I haven't dug into that site too deeply, but it creates the *impression* at least that (1) the Mambo community is large (larger than Drupal's community)
This is probably true.
and (2) there's room for all levels of module development and the status of each project is well understood.
I find it fairly easy through SourceForge's interface (and by extension MamboForge and others like it) to figure out what's useful and what's crap (mostly by looking at a module's activity level and status). It's much harder in Drupal, despite the relatively small number of modules (as compared to SF projects!), to figure out what's useful.
DrupalForge anyone?
The problem is not a dandy name, the problem is that there is no code to allow module classification. Cheers, Gerhard
On 24 Apr 2005, at 18:18, Gerhard Killesreiter wrote:
And just for reference, Mambo features an entire website dedicated to its modules, components, and themes: http://mamboforge.net
I've noticed that site as well. I haven't dug into that site too deeply, but it creates the *impression* at least that (1) the Mambo community is large (larger than Drupal's community)
This is probably true.
They are at least twice at popular/big: http://drupal.org/files/drupal-mambo.png Their forums (http://forum.mamboserver.com/) are much bigger as well. -- Dries Buytaert :: http://www.buytaert.net/
On 24 Apr 2005, at 18:24, Eric Scouten wrote:
Jeff Robbins wrote:
And just for reference, Mambo features an entire website dedicated to its modules, components, and themes: http://mamboforge.net
I find it fairly easy through SourceForge's interface (and by extension MamboForge and others like it) to figure out what's useful and what's crap (mostly by looking at a module's activity level and status). It's much harder in Drupal, despite the relatively small number of modules (as compared to SF projects!), to figure out what's useful.
XOOPS and Postnuke use the SourceForge software as well. Wordpress uses Trac. Plone has its own module/plugin management software. Personally, I prefer to devote my time improving the project module. The fact that we eat our own food, motivates us to improve, refactor and tune Drupal to become a better platform. -- Dries Buytaert :: http://www.buytaert.net/
On Sun, 24 Apr 2005, Dries Buytaert wrote:
On 24 Apr 2005, at 18:24, Eric Scouten wrote:
Jeff Robbins wrote:
And just for reference, Mambo features an entire website dedicated to its modules, components, and themes: http://mamboforge.net
I find it fairly easy through SourceForge's interface (and by extension MamboForge and others like it) to figure out what's useful and what's crap (mostly by looking at a module's activity level and status). It's much harder in Drupal, despite the relatively small number of modules (as compared to SF projects!), to figure out what's useful.
XOOPS and Postnuke use the SourceForge software as well. Wordpress uses Trac. Plone has its own module/plugin management software.
Personally, I prefer to devote my time improving the project module. The fact that we eat our own food, motivates us to improve, refactor and tune Drupal to become a better platform.
The "problem" with that approach is that the project module is not used by many people outside drupal.org. This is probably due to two factors: 1) Even long time Drupal contributors are scared by it. 2) It is too much geared towards software development to be usable for anything else. If we could agree to at least change the policy with regard to 2) (for example removing the hard coded status values (see Nedjo's patch)) you'd probably see more patches or at least interest from other people and thus improvements or at least testers. Cheers, Gerhard
Op 24-apr-05 om 19:23 heeft Gerhard Killesreiter het volgende geschreven:
On Sun, 24 Apr 2005, Dries Buytaert wrote:
On 24 Apr 2005, at 18:24, Eric Scouten wrote:
Jeff Robbins wrote:
And just for reference, Mambo features an entire website dedicated to its modules, components, and themes: http://mamboforge.net
I find it fairly easy through SourceForge's interface (and by extension MamboForge and others like it) to figure out what's useful and what's crap (mostly by looking at a module's activity level and status). It's much harder in Drupal, despite the relatively small number of modules (as compared to SF projects!), to figure out what's useful.
XOOPS and Postnuke use the SourceForge software as well. Wordpress uses Trac. Plone has its own module/plugin management software.
Personally, I prefer to devote my time improving the project module. The fact that we eat our own food, motivates us to improve, refactor and tune Drupal to become a better platform.
The "problem" with that approach is that the project module is not used by many people outside drupal.org.
This is probably due to two factors:
1) Even long time Drupal contributors are scared by it. 2) It is too much geared towards software development to be usable for anything else.
If we could agree to at least change the policy with regard to 2) (for example removing the hard coded status values (see Nedjo's patch)) you'd probably see more patches or at least interest from other people and thus improvements or at least testers.
Another reason why people are probably scared to work with the project.module is the fact that it does too much! (And, I think we have more modules that does this, and would also be better off splitted into more than one module) if we could split the module into 3 or 4 depending modules, it would be probably much easier to get an overview of what needs to be done and - even more important - where it needs to be done. Regards, Stefan.
Jeff Robbins wrote:
And just for reference, Mambo features an entire website dedicated to its modules, components, and themes: http://mamboforge.net
I find it fairly easy through SourceForge's interface (and by extension MamboForge and others like it) to figure out what's useful and what's crap (mostly by looking at a module's activity level and status). It's much harder in Drupal, despite the relatively small number of modules (as compared to SF projects!), to figure out what's useful.
XOOPS and Postnuke use the SourceForge software as well. Wordpress uses Trac. Plone has its own module/plugin management software.
Personally, I prefer to devote my time improving the project module. The fact that we eat our own food, motivates us to improve, refactor and tune Drupal to become a better platform.
Well I find this a fascinating conversation. I've come across Mambo now in a couple of situations and don't really know much about it. However my observations are: 1) Their website is geared heavily towards a less-technical community. They are focussed on end-users, web designers and web masters. 2) Their admin panel gives great demo. 3) Their look is polished and professional. While their product may be technically inferior, their marketing is better (assuming you want more users). Remember - betamax got beat by vhs. I completely understand the "eat your own dogfood approach". I also understand the "focus, focus, focus" approach as well as the "do what you do best" approach. I think that the project module is a great example. My experience with the project module (for bug/feature tracking) is in comparison with bugzilla. Bugzilla looks and feels really terrible - however it really gets the job done. What is the relative importance in having a great drupal project module to other important features? How is this communicated within the community? What is more of a motivation - saying that we're using something of inferior quality and hoping that the pain of using it will encourage developers to meet the challenge? or using something that does the job well and being embarrased that it isn't native drupal? (one thing I noticed is that the forum discussion boards at MamboServer are using a 3rd party commercial product :) ). Anyway - interesting discussion. Dan
On Sun, 24 Apr 2005, Dan Robinson wrote:
Personally, I prefer to devote my time improving the project module. The fact that we eat our own food, motivates us to improve, refactor and tune Drupal to become a better platform.
Well I find this a fascinating conversation. I've come across Mambo now in a couple of situations and don't really know much about it.
Same here. I have just last week had a look at its admin interface. While it is very slick, I think there is a bit too much on it...
However my observations are:
1) Their website is geared heavily towards a less-technical community. They are focussed on end-users, web designers and web masters.
Lots of marketing blurb, I agree.
2) Their admin panel gives great demo.
Maybe we could have a pseudo-demo. By pseudo-demo I mean that we could have a html dump of an admin interface without any working forms. This would save us from needing another database etc. but would people allow to have a look behind the scenes. People who'd like to have a real demo site could go to opensourcecms or what was it called. In any case we should have a prominent link to oscms.
3) Their look is polished and professional.
I like to think drupal.org is too.
While their product may be technically inferior, their marketing is better (assuming you want more users).
I think that most developers wouldn't mind more users, but would prefer not to have just any user...
Remember - betamax got beat by vhs.
I don't see that this is about beating someone. There are lots of CMSes in the world and I rather see this is good than as bad.
I completely understand the "eat your own dogfood approach". I also understand the "focus, focus, focus" approach as well as the "do what you do best" approach. I think that the project module is a great example. My experience with the project module (for bug/feature tracking) is in comparison with bugzilla. Bugzilla looks and feels really terrible - however it really gets the job done. What is the relative importance in having a great drupal project module to other important features? How is this communicated within the community?
The project.module isn't bad at doing what it was designed for. Quite the contrary. Buit since Drupal grows at a rather steep rate we need to improve it.
What is more of a motivation - saying that we're using something of inferior quality and hoping that the pain of using it will encourage developers to meet the challenge?
As I outlined before the problem is that project.module will not get much attention because of its focus on Drupal and drupal.org. Free software development is about scratching one's own itches and I for example can use project.module just fine on drupal.org but cannot use it anywhere else due to design limitations. Thus no itch and no code.
or using something that does the job well and being embarrased that it isn't native drupal? (one thing I noticed is that the forum discussion boards at MamboServer are using a 3rd party commercial product :) ).
Something I'll happily point out to any potential clients. Thanks. ;^)
Anyway - interesting discussion.
According to the "talk is silver, code is gold" mantra we should get some code in the project module just now... Things to consider: - Would it make sense to use actions/workflow.module for it? - Why does it need to have its own comment stuff? Probably in order to have the extended form that we use. This could be a reason to apply the commentapi patch to Drupal and go from there to removing the extra comment handling in project module. - Remove hardcoded status codes. - Introduce better mailed issues. Issues should be mailed similar to how mailman mails digests. Cheers, Gerhard
On Sun, 24 Apr 2005, Dan Robinson wrote:
Personally, I prefer to devote my time improving the project module. The fact that we eat our own food, motivates us to improve, refactor and tune Drupal to become a better platform.
Well I find this a fascinating conversation. I've come across Mambo now in a couple of situations and don't really know much about it.
Same here. I have just last week had a look at its admin interface. While it is very slick, I think there is a bit too much on it...
There may be too much - but it is slick nonetheless. Remember a lot of people "buy" based on initial impressions. They may get disapointed later - but unless the overall experience is terrible - they will just stay connected to what they've got.
However my observations are:
1) Their website is geared heavily towards a less-technical community. They are focussed on end-users, web designers and web masters.
Lots of marketing blurb, I agree.
yes - and "pretty" pictures.
2) Their admin panel gives great demo.
Maybe we could have a pseudo-demo. By pseudo-demo I mean that we could have a html dump of an admin interface without any working forms. This would save us from needing another database etc. but would people allow to have a look behind the scenes. People who'd like to have a real demo site could go to opensourcecms or what was it called. In any case we should have a prominent link to oscms.
why not just have a full db and just use a cron job to keep blowing it away?
3) Their look is polished and professional.
I like to think drupal.org is too.
well - yes and no (IMHO). While in reality drupal.org is well designed from a usability point of view - the graphics peg it as a "project" as opposed to a "product" (IMHO).
While their product may be technically inferior, their marketing is better (assuming you want more users).
I think that most developers wouldn't mind more users, but would prefer not to have just any user...
well this is true to an extent. You don't want growth for growths sake necessarily, but remember there is probably a direct relationship between the number of users and the number of developers. It would be cool if we could double the number of developers working on Drupal without lowering the quality.
Remember - betamax got beat by vhs.
I don't see that this is about beating someone. There are lots of CMSes in the world and I rather see this is good than as bad.
My point was that just because you have great technology doesn't mean you "win" in the marketplace. Drupal deserves more recognition because it is a kick-ass system (and more importantly - community).
I completely understand the "eat your own dogfood approach". I also understand the "focus, focus, focus" approach as well as the "do what you do best" approach. I think that the project module is a great example. My experience with the project module (for bug/feature tracking) is in comparison with bugzilla. Bugzilla looks and feels really terrible - however it really gets the job done. What is the relative importance in having a great drupal project module to other important features? How is this communicated within the community?
The project.module isn't bad at doing what it was designed for. Quite the contrary. Buit since Drupal grows at a rather steep rate we need to improve it.
well I've only used it for software tracking and my experience with it (compared to only slightly more experience with bugzilla) is that feature for feature bugzilla wins hands down.
What is more of a motivation - saying that we're using something of inferior quality and hoping that the pain of using it will encourage developers to meet the challenge?
As I outlined before the problem is that project.module will not get much attention because of its focus on Drupal and drupal.org. Free software development is about scratching one's own itches and I for example can use project.module just fine on drupal.org but cannot use it anywhere else due to design limitations. Thus no itch and no code.
or using something that does the job well and being embarrased that it isn't native drupal? (one thing I noticed is that the forum discussion boards at MamboServer are using a 3rd party commercial product :) ).
Something I'll happily point out to any potential clients. Thanks. ;^)
yes - it would be great if we had a competitive analysis - point by point - the other thing I saw over at MS (hmmm....) was that I couldn't find their CVS :).
Anyway - interesting discussion.
According to the "talk is silver, code is gold" mantra we should get some code in the project module just now...
Things to consider:
- Would it make sense to use actions/workflow.module for it? - Why does it need to have its own comment stuff? Probably in order to have the extended form that we use. This could be a reason to apply the commentapi patch to Drupal and go from there to removing the extra comment handling in project module. - Remove hardcoded status codes. - Introduce better mailed issues. Issues should be mailed similar to how mailman mails digests.
Cheers, Gerhard
3) Their look is polished and professional.
I like to think drupal.org is too.
well - yes and no (IMHO). While in reality drupal.org is well designed from a usability point of view - the graphics peg it as a "project" as opposed to a "product" (IMHO).
Well, when I first noticed the new mamboserver.com site, it looked too drupal.org-ish to me... and it still is. Look at the sidebar, the footer, the blurbs on the homepage :) Goba
On 24 Apr 2005, at 23:15, Gabor Hojtsy wrote:
3) Their look is polished and professional.
I like to think drupal.org is too.
well - yes and no (IMHO). While in reality drupal.org is well designed from a usability point of view - the graphics peg it as a "project" as opposed to a "product" (IMHO).
Well, when I first noticed the new mamboserver.com site, it looked too drupal.org-ish to me... and it still is. Look at the sidebar, the footer, the blurbs on the homepage :)
This issue has also been raised in both the Mambo and Drupal forums. -- Dries Buytaert :: http://www.buytaert.net/
Well, when I first noticed the new mamboserver.com site, it looked too drupal.org-ish to me... and it still is. Look at the sidebar, the footer, the blurbs on the homepage :)
I haven't been over to mamboserver.com for a while, but I just checked it out now to see what's changed. And you're right, it DOES look drupal.org-ish. In fact, the 'what is mambo...' blurb and the tabs are so similar to drupal.org, that I suspect they've copied us. In which case... COOL! Mambo is copying Drupal! We're being used as a benchmark for a site with double our user base! However, I agree that Mambo's site design still looks decidedly corporate and upmarket, while Drupal's site design clearly says 'community project' and 'work in progress'. I tried to think of some other sites that have similar designs, for comparative purposes, and this is what I came up with: mamboserver.com -> apple.com drupal.org -> lego.com Take a look at the pairs of sites side-by-side, and you'll see what I mean. The similarities are mainly in the choice of colour. Maybe the Drupal community should look into making little plastic toys, just as a fundraiser on the side? :-). Clean, modular, accessible, semantic, usable, and [free... err, I mean...] reasonably priced plastic toys, of course.
On 24 Apr 2005, at 22:52, Dan Robinson wrote:
2) Their admin panel gives great demo.
Maybe we could have a pseudo-demo. By pseudo-demo I mean that we could have a html dump of an admin interface without any working forms. This would save us from needing another database etc. but would people allow to have a look behind the scenes. People who'd like to have a real demo site could go to opensourcecms or what was it called. In any case we should have a prominent link to oscms.
Note that Drupal's project page on drupal.org has a "demo link" that points to the demo at opensourcecms.com. In other words, there is a demo, although it might not be very visible.
I completely understand the "eat your own dogfood approach". I also understand the "focus, focus, focus" approach as well as the "do what you do best" approach. I think that the project module is a great example. My experience with the project module (for bug/feature tracking) is in comparison with bugzilla. Bugzilla looks and feels really terrible - however it really gets the job done. What is the relative importance in having a great drupal project module to other important features? How is this communicated within the community?
The project.module isn't bad at doing what it was designed for. Quite the contrary. Buit since Drupal grows at a rather steep rate we need to improve it.
The project module has been making progress, and still is. The past three months I added (i) CVS integration, (ii) compilation of a per project developer lists and (iii) automated code reviews/reports. Furthermore, we have nedjo's patch waiting to be tested and it looks like Steven and Ber began investigating some of the imminent usability issues. At the same time, we encourage people to make the project module more generic.
What is more of a motivation - saying that we're using something of inferior quality and hoping that the pain of using it will encourage developers to meet the challenge?
I can't speak for others but I'd rather spend my time improving the project module than writing conversion scripts or maintaining a separate project site. Furthermore, I'm convinced that the final outcome will be better than using Bugzilla or SourceForge. Call me stupid, but if I wasn't convinced I/we could make a better a product than PHP-Nuke, ThatWare, Scoop or Slash, we wouldn't be working on Drupal to begin with. Sometimes it takes some persistence.
Anyway - interesting discussion.
According to the "talk is silver, code is gold" mantra we should get some code in the project module just now...
Things to consider:
- Would it make sense to use actions/workflow.module for it? - Why does it need to have its own comment stuff? Probably in order to have the extended form that we use. This could be a reason to apply the commentapi patch to Drupal and go from there to removing the extra comment handling in project module. - Remove hardcoded status codes. - Introduce better mailed issues. Issues should be mailed similar to how mailman mails digests.
Great start! :-) -- Dries Buytaert :: http://www.buytaert.net/
On Mon, 25 Apr 2005, Dries Buytaert wrote:
demo site could go to opensourcecms or what was it called. In any case we should have a prominent link to oscms.
Note that Drupal's project page on drupal.org has a "demo link" that points to the demo at opensourcecms.com. In other words, there is a demo, although it might not be very visible.
Now you see how visible it is. ;)
The project.module isn't bad at doing what it was designed for. Quite the contrary. Buit since Drupal grows at a rather steep rate we need to improve it.
The project module has been making progress, and still is. The past three months I added (i) CVS integration, (ii) compilation of a per project developer lists and (iii) automated code reviews/reports.
While I think that all three improvements are interesting and usefull additions (i especially like iii) they IMHO didn't address immediate needs.
Furthermore, we have nedjo's patch waiting to be tested and it looks like Steven and Ber began investigating some of the imminent usability issues. At the same time, we encourage people to make the project module more generic.
Ah, is this the official position now? Good to know.
What is more of a motivation - saying that we're using something of inferior quality and hoping that the pain of using it will encourage developers to meet the challenge?
I can't speak for others but I'd rather spend my time improving the project module than writing conversion scripts or maintaining a separate project site.
Goes without question.
stupid, but if I wasn't convinced I/we could make a better a product than PHP-Nuke, ThatWare, Scoop or Slash, we wouldn't be working on Drupal to begin with. Sometimes it takes some persistence.
Yeah. How about my revisions patch? Apply it. Right Now(tm).
- Would it make sense to use actions/workflow.module for it? - Why does it need to have its own comment stuff? Probably in order to have the extended form that we use. This could be a reason to apply the commentapi patch to Drupal and go from there to removing the extra comment handling in project module. - Remove hardcoded status codes. - Introduce better mailed issues. Issues should be mailed similar to how mailman mails digests.
Great start! :-)
I am glad you like the ideas, but could you indicate which you _really_ like? I created feature requests for the ones that aren't there yet. http://drupal.org/node/21272 http://drupal.org/node/13539 http://drupal.org/node/17052 http://drupal.org/node/21273 Cheers, Gerhard
While we're discussing stuff like drupalforge.org, I'd like to draw developers attention to this post I've just made: Proposal: Visibility for Drupal and contributors http://drupal.org/node/21277 If the proposal gets acted on I think it has the potential to boost contributions to Drupal, both code and documentation, and raise the profile of Drupal as a whole. We'll one can hope ;-) Best regards, Robert Castelo [MegaGrunt]
I don't want to keep talking because I feel I'm violating the silver/gold business (which is a good rule of thumb :) ). Don't get me wrong on my comments, my point really is that with better packaging we would get more traction, which gives us more people, which gives us more developers which then gets us more coders (or talkers.... depending :) ). Anyway I was really struck by what was said re: the Project module: ... The project module has been making progress, and still is. The past three months I added (i) CVS integration, (ii) compilation of a per project developer lists and (iii) automated code reviews/reports. Furthermore, we have nedjo's patch waiting to be tested and it looks like Steven and Ber began investigating some of the imminent usability issues. At the same time, we encourage people to make the project module more generic. ... I went to the project page for Project and got - ... This module enables teams to track outstanding items which need resolution. It provides e-mail notifications to members about updates to items. Similar to many issue tracking systems. ... I'm not criticising - just pointing out that there is a huge knowledge gap - if someone is coming from the outside and evaluating then they are going to miss a huge gold-mine of functionality. Anyway - at this point I'm hoping that I will come back later with some concrete deliverables to help out. Meanwhile back to the silver mines. Dan
On 24 Apr 2005, at 22:52, Dan Robinson wrote:
2) Their admin panel gives great demo.
Maybe we could have a pseudo-demo. By pseudo-demo I mean that we could have a html dump of an admin interface without any working forms. This would save us from needing another database etc. but would people allow to have a look behind the scenes. People who'd like to have a real demo site could go to opensourcecms or what was it called. In any case we should have a prominent link to oscms.
Note that Drupal's project page on drupal.org has a "demo link" that points to the demo at opensourcecms.com. In other words, there is a demo, although it might not be very visible.
I completely understand the "eat your own dogfood approach". I also understand the "focus, focus, focus" approach as well as the "do what you do best" approach. I think that the project module is a great example. My experience with the project module (for bug/feature tracking) is in comparison with bugzilla. Bugzilla looks and feels really terrible - however it really gets the job done. What is the relative importance in having a great drupal project module to other important features? How is this communicated within the community?
The project.module isn't bad at doing what it was designed for. Quite the contrary. Buit since Drupal grows at a rather steep rate we need to improve it.
The project module has been making progress, and still is. The past three months I added (i) CVS integration, (ii) compilation of a per project developer lists and (iii) automated code reviews/reports. Furthermore, we have nedjo's patch waiting to be tested and it looks like Steven and Ber began investigating some of the imminent usability issues. At the same time, we encourage people to make the project module more generic.
What is more of a motivation - saying that we're using something of inferior quality and hoping that the pain of using it will encourage developers to meet the challenge?
I can't speak for others but I'd rather spend my time improving the project module than writing conversion scripts or maintaining a separate project site. Furthermore, I'm convinced that the final outcome will be better than using Bugzilla or SourceForge. Call me stupid, but if I wasn't convinced I/we could make a better a product than PHP-Nuke, ThatWare, Scoop or Slash, we wouldn't be working on Drupal to begin with. Sometimes it takes some persistence.
Anyway - interesting discussion.
According to the "talk is silver, code is gold" mantra we should get some code in the project module just now...
Things to consider:
- Would it make sense to use actions/workflow.module for it? - Why does it need to have its own comment stuff? Probably in order to have the extended form that we use. This could be a reason to apply the commentapi patch to Drupal and go from there to removing the extra comment handling in project module. - Remove hardcoded status codes. - Introduce better mailed issues. Issues should be mailed similar to how mailman mails digests.
Great start! :-)
-- Dries Buytaert :: http://www.buytaert.net/
On 24 Apr 2005, at 11:18 AM, Gerhard Killesreiter wrote:
As I outlined before the problem is that project.module will not get much attention because of its focus on Drupal and drupal.org. Free software development is about scratching one's own itches and I for example can use project.module just fine on drupal.org but cannot use it anywhere else due to design limitations. Thus no itch and no code.
I agree - generalizing the project module will make it more powerful and applicable, encouraging adoption and development, while providing benefits to managing projects in and around Drupal.org, too - for example, documentation! Every sufficiently large website project needs some kind of project/issue management system, at least during the initial development. I've tried to use Drupal's project module for this, but it wasn't suitable, mostly for reasons already discussed. It would be an added attraction to people considering Drupal as a platform for their sites if they had built-in functionality for implementing project management. Djun -- Djun M. Kim, Director djun.kim@cielosystems.com Cielo Systems Inc. http://www.cielosystems.com Strategic Software Research Tel: (604) 739-3941 302 - 1298 10th Avenue West FAX: (604) 739-3943 Vancouver, BC, V6H 1J4 Mobile:(778) 895-1379
Personally, I prefer to devote my time improving the project module. The fact that we eat our own food, motivates us to improve, refactor and tune Drupal to become a better platform.
I think with a few changes we can go a long way already. For example this issue: http://drupal.org/node/20991 Another idea is to give projects a more 'at home' feel by having a per-project block which acts like a per-project menu to issues, cvs messages, etc. as well as lists stuff like author, latest release, etc. It would appear whenever you are browsing a project's pages or issues. Steven Wittens
Personally, I prefer to devote my time improving the project module. The fact that we eat our own food, motivates us to improve, refactor and tune Drupal to become a better platform.
I think with a few changes we can go a long way already. For example this issue: http://drupal.org/node/20991
Another idea is to give projects a more 'at home' feel by having a per-project block which acts like a per-project menu to issues, cvs messages, etc. as well as lists stuff like author, latest release, etc. It would appear whenever you are browsing a project's pages or issues.
Good idea. But pileing up more features into the module will not make it easier to maintain. It needs a weblink module like rethinking process IMHO. Goba
participants (21)
-
Adrian Rossouw -
Allie Micka -
Bèr Kessels -
Chris Messina -
Dan Robinson -
Dries Buytaert -
Eric Scouten -
Gabor Hojtsy -
Gerhard Killesreiter -
Jeff Robbins -
Jeremy Epstein -
Jose A. Reyero -
Karoly Negyesi -
Moshe Weitzman -
Nedjo Rogers -
puregin -
Robert Castelo -
Stefan Nagtegaal -
Steven Wittens -
Syscrusher -
Tim Altman