Hi Guys,
Just thought I'd post a discussion starter up here for anyone else who is experiencing the following symptoms:
- 70/80% of your time is spent troubleshooting your drupal installations and 20/30% actually working with your sites
- confusion about which modules are which, what difference there is between modules that do the same thing
- uncertainty about whether you should install a.module or b.module or c.module and which will be maintained
- you have stumbled across a fantastic, useful.module at a non drupal.org site purely by accident
- You find it frustrating to get quick responses from the forum and don't know about the IRC support channel
- You learn about new developments or essential fixes by visiting drupal.org and spotting posts by chance while browsing the RECENT POSTS
This is not intended as negative criticism...it's intended as a constructive discussion point, because, while I love Drupal and it's community etc. I have noticed a general scattering of late that has me slightly worried...
A good, simple, example might be the emailthispage functionality which now has (I think as many as) 4 contributed modules. All doing essentially the same thing, but, slightly differently.
Another example would be how drupal.org and Drupal development is being inadvertantly "forked" with other non drupal.org sites, but related, turning into mini-development hubs for "their own" Drupal, not the drupal.org Drupal...if you know what I mean.
So while they aren't official "forks" or breakaway versions of Drupal, they are having a scattering effect on development (drupal.org). It's extremely difficult now to keep track of what's going on.
the multiple emailthispage.modules is a symptom of this..it's quite likely that the other 3 developers didn't know that there already was a module that does exactly what it says on the tin.....or they didn't realise that it's better to have 1 brilliant module rather than 4 similar modules...i.e. instead of unleashing their own emailthispage.module they should have submitted patches (improvements) to the core emailthispage.module.
There's a similar emerging problem with how multimedia content related modules are being developed...i.e. there are about 6 or 7 modules out there (both on and off drupal.org) that are related to handling audio...including the music.module, audio.module, podcast.module, playlist.module, flexinode.module, mediahandler.module etc. etc.
That's a crazy situation and while the entusiasm and skills out there are great...I think it's detrimental for drupal to evolve this way.
Wouldn't it be better if those developers (audio related modules) agreed upon a "betamax/vhs" set of functions that would go into Drupal core and then they go off and develop their add-ons?
Of course it would be..but the problem is because of this "scattering" or general Drupal community dilution I'm talking about, it's highly likely that the developer of a.module didn't know that someone else was working on a b.module...that does the same thing.
There are some great useful.modules out there..you can stumble across them on google, like I did when I did a search for music.module in google and forgot to put in the site:www.drupal.org bit in. Unfortunately, those great.modules are going under the radar because of the general scattering I'm talking about.
Another example would be the frustrations some are experiencing (and voicing) on the Drupal forums...
I have been playing with and using drupal for over 1 year now.....and I do my best to contribute back when I can..and with what I can....I only realised there was an IRC channel for drupal-support a few weeks ago when the drupal.org site was down. I had never used IRC before..logged on and realised that the forums on here are being diluted, because most are going to the IRC channels for support.
Anyone else have a similar nagging concerns?
or is it just standard stuff when a great tool like Drupal evolves and gets too big to be contained within one site?
Dub
Comments
Evolution
I personally have blog searches set up for anything Drupal-related. Often, people that develop/post elsewhere a) don't know the process for creating a CVS account, b) are scared of CVS, or c) have had their CVS account rejected.
For a), I always point out the process and invite the people to come to drupal.org
For b), well, you *have* to learn CVS to contribute. If you can't, then long term, you won't be able to keep your module up to date, and people won't be able to work on it together.
For c), I have tried to clarify this process -- see http://drupal.org/node/30461
Audio is something that Colin (who works for Bryght) and Farsheed (at CivicSpace) have both been working on together. They have also I believe touched base with all other people working in this space (yes, including the podcast guy). There is general acceptance that the audio.module, which is modelled on the image.module, will become the basis for audio-related content in Drupal. The playlist module is now complete as well. The place for this discussion should be the Media and Document Management forum.
It's unlikely that audio will go into core anytime soon, if ever. This is not something that everyone needs out of a CMS, and Drupal's modular design means it's easy enough to add.
I'm not sure what you mean by "their own Drupal". Can you point to examples?
I'm sorry to hear you spend such a long time troubleshooting. I would recommend that you only work with modules that you KNOW are solid -- this can be observed by looking at the maintainer, the number of open bugs, and how long it takes for a response from the maintainer.
IRC support: it is an extra channel for real-time support. It is completely staffed by volunteers, just like the forums. I don't tend to hang out in IRC, since I don't have the time for it, so I continue to provide support here in the forums.
Now that we are on new hardware, we can also look at tuning some of the features of Drupal.org -- like taxonomy and/or ratings for modules.
So....all of this needs people to lead the charge/organize/get people to work together. There is no simple fix, other than to continue to be inclusive, to encourage people to work together, to educate about similar modules, and so on. So be proactive -- talk to module maintainers, ask them to work together, get them to merge modules and put duplicate modules in the attic.
points taken Boris..but, you have been with Drupal for 2 years..
Hi Boris,
Points taken..but, you have been with Drupal for 1 year and 52 weeks (you must have joined this week two years ago! happy er..drupalday..!).
There is an emerging culture where if a module doesn't do what you want it to...people are hacking their own new fork of an existing module, as opposed to submitting a patch.
And in some cases, such as the emailthispage.module example..those hacks get released as modules and we end up with 4 or 5 dirfferent modules that do the same thing and the confusion that goes with that..
you say: "all of this needs people to lead the charge/organize/get people to work together".
I totally disagree...and it's the main point I raised this discussion.
What you're really saying is "all of this needs people to learn how we work".
The enthusiasm, skills and love of Drupal is out there...the problem is NOT that people need to be "led to work together"...they need to be "allowed to work together".
At the moment, that's impossible/daunting unless developers don't mind spending a bit of time working out how the CVS works with Drupal.
On the flip side, I can see the difficulty in granting people CVS permissions willy-nilly...but surely a more sensible balance could be found between encouraging people to work together and maintaining some form of security around the Drupal core.
Would it not be an idea to have an extra section to the Drupal.org site where people can post their DIY/hacked/other modules?
I'm guessing that it's too late to make drupal.cvs easier to use and more intuitive for developers. And I'm also guessing that it's too difficult to grant CVS permissions to unkown entities...so an "untested, unplugged and unsigned" module section - if it was on drupal.org would help bring development back into drupal.
I have stumbled across some great useful modules (including the FLEXIMAX.MODULE patch and the TRACKING.MODULE) purely by accident on google...we should be encouraging developers to post those gems on drupal.org instead of elswhere..
While the wake following mambo's hiatus is still very vivid...I just thought I'd raise this discussion point now....I think if people are "allowed" to contribute to Drupal.org rather than "led"...as you put it...we might have a stronger community and a more virbrant, centralised development community...instead of having to setup blog feeds and do google searches to see what''s going on.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Sorry, I still stand by my
Sorry, I still stand by my statement that we have to show/educate/encourage people to work together. It *IS* a cultural thing...which is why I always try and work together with people and encourage developers to patch, etc. And read what I said (as well as go and look at posts, e.g. here: http://www.echoditto.com/node/690 -- all I do is encourage people to come to Drupal.org and add to CVS.
I also have championed more access to CVS, but CVS is NOT the issue...read my link on the patch process -- you do not need access to CVS to patch a module. Drupal CVS is *no different* than any other CVS system. It *cannot* be made easier to use. If developers can't learn it, they can't participate in open source development....EXCEPT on Drupal.org, where we have a patch process in addition to CVS.
(I find it somewhat insane that I'm arguing the opposite point of a giant flame fest I had with Gerhard on the infrastructure list)
So, what are my suggestions to you? Wherever you see people not working together, contact them via the forums or their contact pages and ask them to collaborate. Contribute suggestions on how modules could be merged. If you see a module posted on another website, ask them to contribute to Drupal.org.
Hope all that is clear....
fair points..
good points Boris and I tend to agree with you re: the status quo with the current CVS.
Rules and regulations are an important and essential element for any community (online or offline).
the current CVS and the way it works is something that the core developers understand and are familiar with. The words "if it ain't broke don't fix it" springs to mind.
there is scope, however to do the following:
organise what's available better
It is actually a very very laborious process to trawl through the modules pages, CVS repositories (contrib) and the sandbox repositories.
There should be a new category that lists orphan modules or modules that are in the cvs.drupal.org site, but, not officially released.
bringing it back home
There are some stunning modules and ideas that don't see the light of day because the developers are obviously too busy, too tired to have to learn a new CVS system to contribute formally or there is simply a language barrier.
Joshks MUSIC.MODULE or kiev1's FLEXIMAX.MODULE are classic examples.
planet Drupal may resolve that "bringing it back home" thing. But i think it might be better to introduce another level into the drupal.org site that does the following:
(a) module category/classification
(b) drupal version
(c) brief description
(d) link to a demo/screenshot
(e) link to download a zip
(f) authors details
(g) drupal.org user votes*
That solution is extremely simple and helps nurture community interaction while at the same time maintains drupal.org as a hub for support & new modules. It doesn't detract from module patches...because everything is organised in a more sensible and easy to access fashion, it's very obvious to all that a module or similar module already exists..so they are better off submitting a patch to improve an existing module rather than unleash a new module.
The same principle maybe applied to themes.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Please contact me regarding CVS if you need more explanation
The fundamental point you are missing is that "Drupal CVS" is no different than any other CVS system on the planet. CVS is hard. Period. Your statement of developers "too tired to have to learn a new CVS system to contribute formally" misses the point.
I think Colin covered the music.module below -- it was purpose-built for Music for America, and as such has too many extra functions to be able to build on top of. Also, AFAIK, it was in josh's sandbox. Until a developer creates a project and moves it out of your sandbox, it is not a released project. If you have a CVS account, there is nothing stopping you from doing those two steps.
Let me state again: you CANNOT develop a module, nor maintain it, without having it in a revision control system (RCS). The RCS that is used on Drupal.org is CVS. We can't lower the barrier to entry of learning CVS, and there is no way that there are enough extra people to take over the task for someone that won't learn it.
An example. developer1 has created useful.module. They stick it into your system. developer2, who has a CVS account, commits it to CVS. First patch comes in. Who reviews the patch? Well, developer1 does. He says it looks fine. But...can't apply the patch, because they don't know how to use CVS. Asks developer2 to do it. Wait! Patch doesn't apply cleanly. Developer2 must debug and merge in code, then commit. Then developer1 has some feature additions. Posts them as a (giant) patch. Developer2 goes to apply the patch. Wait! Patch doesn't apply cleanly because developer1 was working with a different version of the code, which is exactly what a revision control system like CVS is designed to prevent. I hope that was a very clear example of why people who are maintaining modules must learn CVS.
Look at all the comments below of "but how do we know if the module will continue to be maintained". Checking into CVS is one extra little bit of insurance that the code can be maintained now and into the future in a sane manner.
"jump through hoops to get a CVS account just to share a good idea": I agree there have been issues with the system. I have fought hard to get them fixed. If you look through my various posts, there is exactly one hoop -- fill out the CVS account request page.
"A popular useful.module will attract maintainers and patchers naturally": who have to use CVS in order to fix the code.
So...let's drop the CVS is too hard arguments and focus on what you actually want. A central drop off spot for random bits of code. As I have suggested before, I suggest you gather support, volunteers, etc., come up with a plan for implementing it, even come up with a working site, and we can see about placing it at (for example) forge.drupal.org. You could likely do this with project module out of the box.
We shouldn't change the Drupal CVS
I think it's wrong to change the status quo with the existing CVS system. The drupal developers are comfortable with it. It's similar to other collaborative programming platforms and it would be madness to change it.
I like the fact that it is difficult to get a CVS account and there is a tight control over how it works.
I also think it's wrong to think that
That is simply not true.
As I understand it, ANYONE can create and maintain a module.
I'm not sure if you're reading my posts. But, my suggestion in my previous post was NOT to change how the Drupal CVS works...it was a suggestion to extend development out in a simple and savvy way so that great ideas, modules in development don't go under the radar.
Why is it so difficult to make suggestions on here without getting flak?
If you read the suggestion in my post, it offers a way for drupallers who are not familiar with Drupal CVS, are too busy to learn drupal CVS or there is a language barrier with getting to grips with how the Drupal CVS works an opportunity to share their ideas with the drupal community.
It does *NOT* conflict with the existing, bordering on precious, Drupal CVS system.
The bottom line is *ANYONE* can develop a module and *ANYONE* can maintain a module.
The problem is that the community and development is getting scattered. the left hand doesn't know what the right hand is doing. And we end up with scattered development, great ideas and superb modules that go under the radar, because there is a lack of a bridge or link to non Drupal CVS ideas/modules/development.
The result is crazy situations like the music.module which was posted 3 months ago...yet as of today, we don't have a finished audio.module and we have the flexinode.module, podcast.module, playlist.module, mediahandler.module and probably many more we don't know about because of the scattered community. btw, Colin works for Bryght, so I can understand why he saw it as a better idea to strip apart a great module first to develop for the new bryght record label services rather than tidy up the (superb) music.module for the drupal.org community and then develop the Bryght stuff later. that's totally understandable.
From a drupal perspective, it's a pity, because instead of having a great module to work with 3 months later..we have none..(audio.module is still in development). and instead of a cohesive approach, we have none. We end up with scattered development and a bevvie of modules doing the same thing. In the long term what Colin brings back to Drupal will be superb and far superior than a patched music.module. I can see that already...but, along with the audio.module..we have a clutter of scattered development and multiple modules. Confusion.
Another example is the emailthispage.module where developer A didn't know that there was already a module created by Developer B.
Another example is the mail.module, subscriptions.module, notify.module and probably many more we don't know about. (Is the simplenews.module yet another of that genre?)
I stumbled across a great fleximax.module patch for flexinode recently. It is superb. The problem was that the author didn't speak english and hadn't got a clue what the drupal handbook guidelines meant for submitting patches/modules etc.
So he gave up.
I contacted the guy (kiev1.org) and offered in whatever way I could to acts as a form of a conduit or interpreter to help get his module into a patchable format that could be applied to the flexinode.module.
The FlexiMAX thread is an interesting one..and a very good illustration of how my idea in the previous post would work:
http://drupal.org/node/30376
No offence to Kiev, but no matter what you do with the handbook pages, he would not be able to grasp what they mean. You can tell from his posts on that thread that english is not his first language.
Progress with fleximax is slow, as I'm very new to php and am learning as I go along. If a more savvy php programmer or drupal developer had of spotted kievs fleximax idea - it would have been done and dusted a long time ago.
I notice some developers on here saying that "sometimes it's easier to write something from scratch"...which worries me. Isn't standards and protocol the fundamental buildling block of collaborative development?
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
I'm not giving you flak
I was trying to give an outline of what it means to use a revision control system to maintain and develop software.
Please stop using the phrase "Drupal CVS" -- Drupal uses CVS, but this CVS is identical to all other such systems. It's not "similar to other collaborative programming platforms"....it is identical. CVS is CVS is CVS, and is used by 100s of thousands of projects, businesses, etc. around the world. If you develop software, you should learn it.
Not in a distributed multi-user fashion with more than one person adding to the code without using a revision control system. If the person hosts their own such system, then yes. My example of developer1 and developer2 was meant to illustrate that. Please ask questions if anything is unclear.
I'm just going to re-iterate my suggestion:
Dub, I'll send you an email with a login to a site.
anyone *can* develop a module...
Boris,
I cannot disagree more...anyone *CAN* develop a module...and people *DO* create modules. And those same people *MAINTAIN* their modules.
I know because I have stumbled across them on other sites. Not just once off, "here's a bit of code", but, modules with a legacy of versions.
THERE ARE OVER 30 DRUPAL MODULES AT THIS SITE:
http://www.settingtheworldtorights.com/node/417
All those modules were developed *WITHOUT* the drupal revision control system and is a proof of concept that is very hard to ignore. Some of those are superb modules...
The author has been invited to contribute to Drupal, but, has admitted that he wouldn't be able to guarantee regular maintenance.
Under my proposal there is at least the opportunity to bring those modules into the development system at Drupal and at the very very least it would avoid the scenario of a drupal developer duplicating work already carried out.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Read me again
One person can maintain it all they like. As soon as two people try and maintain code, a revision control system is required in order to merge changes between N people.
I understand what you're saying Boris....
let me try and explain in a different way
...modules are based on ideas first, code second...
...they are organic.
...modules are "born" from the work of 1 developer.
...modules "grow" and evolve from the work of multiple developers.
...the current way of doing things stunts growth and great ideas.
I don't think I can put it any clearer or simpler than that.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
"If you develop software, you should learn it." - wrong.
If you need CVS, you should learn it.
Remember the origins of PHP itself, and how PHP is viewed as an inferior language by most "professional developers", while it is good for some - but not all areas of developement. It's fast, easy to learn, forgiving, requires no special coding style or developement method ...
I saw some tout Lisp as the "real good" solution to do Drupal, and I would agree to some point - but only from a computer science point of view. Getting people to participate on a Lisp project would be very tough. Besides, doing it in a *real* functional language with no variables at all - like Joy - now that would be cool, and probably very fast too. But then if speed was essence then the K and Q vector-based languages with their Oracle-dusting database would be even better - only a bit demanding on CS graduates with no love for the APL-family of languages.
The point is, CVS is not and should not be held as a prerequisite for participating in evolving Drupal through modules or contributions. Only a minute, tiny-tiny fraction of PHP developers use CVS ...
;-)
striking a blanance...
your programming knowledge is a lot more indepth than mine, so I stand corrected..but, perhaps, ironically, I'm not really suggesting any change in the way drupal manages collaborative submissions.
I'm merely trying to objectively discuss how things can be better displayed and how an extra page of non-drupal "orphan" or "here's one I made earlier to do this" modules.
Unfortunately, there seems to be a taboo about discussing anything that touches on the CVS.
thanks for your input anyway, Eldarin.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
I agree with your points
And when it comes to topics being turned into defensive bickering to get any change around - a quick reminder of what drupal.org in effect is now is in place.
drupal.org users and donators have a right to ask for improvement - and denying such change proves silly to the history and spirit of opensource projects.
;-)
I love you! I about you have
I love you!
I about you have not forgotten. I have not thrown. I know that you think also what there are problems, but I simply have no time now and then hardly I shall complete later
>and hadn't got a clue what the drupal handbook guidelines meant for submitting patches/modules etc.
I understand that is diff and patch and cvs - as I for a long time use linux - but all that I have offered I have offered and now have a little stopped, and then I shall continue, I lazy and have thought that you or somebody continue that that I have begun:)
I agree to do or in the patches to flexinode or the new module - me all the same, it is necessary flexinode owner to ask.
I agrees that badly if are formed duplicated modules, but it is possible to make any collection of informal modules (often owners throw the modules) and then already to decide what better to include in an contributed modules.
In understanding of documentation Drupal there are no difficulties, the truth not all can be found ideas at once, necessary to sort modules on groups and functions
>I notice some developers on here saying that "sometimes it's easier to write something from scratch"
To work is necessary in common and I Drupal respect for simplicity of understanding of a code
you are over complicating it Boris
just to pick up on your convoluted example, you're totally over complicating it.
here's how it works in baby steps:
THE STATUS QUO:
THE PROPOSED NEW METHOD:
DOMINO-EFFECT OF THE NEW SUGGESTED METHOD:
DOMINO EFFECT OF THE NEW SUGGESTED METHOD ON DEVELOPMENT:
SLIGHT VARIATION OF SAME:
I hope that makes sense...please note Boris that I have *NOT* suggested we drop the drupal CVS at any stage. Nor have I even suggested it should be changed.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
I'm not arguing against your
I'm not arguing against your system. I'm saying:
a) that there is not enough bandwidth (i.e. lack of "Savvy drupaller" with time on their hands) for this to happen on Drupal.org
b) trying to explain the realities of software development and the use of revision control systems.
We all know that a better display of modules is needed here (functional/other displays). nedjo is being funded by CivicSpace to fix bugs in the project.module. Here's a recent discussion where killes and I agree (!!! :P) that two vocabularies would be good: http://drupal.org/node/32121
I would suggest joining the Documentation team to suggest the "fixed" taxonomy terms to organize the modules with.
But *enabling* users to contribute without CVS ...
.. is not that hard to accomplish.
I agree that teams and organizations need to use CVS to get serious work done - and for continuation of projects etc.
Not every drupal.org change need complex changes - there are small changes which can help everyone - *if* these changes would get realized. Then content/quality could get input by the hordes of Drupal-wise who frequent drupal.org.
An example of such would be a better display of the modules like everyone seem to agree on. CVS should have nothing to do with the listing of modules.
;-)
Users can contribute without
Users can contribute without cvs, they can attach patches to the project in question, no cvs needed. This has been said before. And again.
You now seem to be advocating for us NOT to use a CVS system. Content and quality and how to test and give feedback in an accurate and consistent manner are documented in the handbook. All you need is a drupal.org account.
Content for documentation requires that you click, Create content, then book page. Now, you write your contribution. If you want immediate feendback, sign up to Drupal-docs list and send a note out, otherwise, when someone checks the moduleration queue, they can review it and approve it.
CVS has eveything to do with modules. Every module is stored in the CVS system. Project module packages them for download and presents the list and the versioning information for display in drupal.org. If we did not have this computer automation, then nothing would happen because we already have more people who talk about work than actually do work
So we are back to in a complex worldwide project with more then two contributors, you must have a revision control system (CVS in this case) and without such, software development in a distributed fashion is not realistically posible.
There are around 300 cvs accounts already.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
You are wrong.
I said that I agree that teams and organizations need CVS, individual developers/contributors don't always need it - and especially Drupal module contributors should not be required to use it.
That means that Drupal core should of course use it, and perhaps someone collaborating on module developement would use it - but it should not be forced on each and everyone who would like to contribute a module on drupal.org.
It would be up to the module maintainer/copyright holder to gather the patches and update for new releases. Isn't that right ?
;-)
You keep patting your own back, saying everyone can contribute without CVS - when that is in total contradiction to anyone who wants to submit a module for listing on drupal.org. They need to apply for a CVS account, might get turned down by a wink of someone because their contribution is not worthy, or too much cruft etc.
The latest example I remember - completely contradicting what you are saying - is the acidfree.module How do I get my module into the contribution tree?
He was flatly turned down to contribute his module because of what I think appropriately can be called red tape bureaucracy.
Now there is another one in the same thread - the author of the premium.module - which also seems a victim of this political attitude, probably there are numerous others. It's a no good approach being displayed. The Mega Drupal collection also spring into mind as someone receiving gripes instead of being allowed to contribute on drupal.org.
You mean the acidfree module
You mean the acidfree module which I made sure had their account approved, prompted me to revamp the list of qualifiers/documentation for patches vs. a CVS account? That module?
The acidfree module that is available for download here?
c'mon guys...can we get back on a more constructive vibe..
Boris,
can we try and get back on a positive, constructive vibe...
the acidfree module is another classic example of how the current status quo is stunting growth.
Developed, finished, done and dusted on august 2nd, it took the best part of 2 months for the module to appear on the drupal community radar.
If we were to think outside the box a little on this one..and consider how the contributer must feel...after putting in all the extra hard work in preparing it for release to the community..I wouldn't be surprised if the developer setup his own drupal[variation].org site posted his module up there and increased the general scattering & dilution of the community.
That's not a contribution culture that is wise to encourage or maintain, in my humble opinion and it's not rocket science to embrace and harness the enthusiasm to share, rather than what is happening at the moment, which is to delay, hamper and dilute that enthusiasm.
This is not a once off thing. every webmaster and his dog is playing with ajax at the moment. under the current contributers model...the holy grail of ajax-4-drupal module might be sitting somewhere, out there, unknown to all. More importantly unkown to all those drupal developers who are probably beavering away in their own scattered corner, developing their own little ajax API or module for drupal.
Similarly, the demand for mobile functionality and voip will (in my opinion) grow significantly over the next 12 to 18 months to the point where websites will require wireless device compatibility as standard..
I've already received an email to keep quiet about a certain multimedia module I was using as an example of how flawed the contribution process is.
And Boris, please note, I have not stated once that we should change the way CVS accounts are granted, how the CVS works or revamping anything. I'm just suggesting a few minor changes to the general architecture of drupal.org to allow for a more dynamic and community driven contributions process that puts drupal.org back on the map as THE COMMUNITY HUB FOR DRUPAL not just one of the places to visit if you're looking for decent ideas or help.
I hope to jaysis that makes sense...
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Ahhh ..
not biting your flamebait on this one, Boris (use some other tackle). You should read my entire post and the post it replied to as a minimum, not just the fact that I linked the topic. My example contradicted the statement that anyone can contribute without access to CVS that Steven tried to sneak in there.
;-)
You veteran guys are too quick on your guns. Have some patience with us clueless newbies ... some pity ...
;-)
PS! Thanks for displaying and pulling the red tape off that one, though.
in the meantime, a small step in the right direction
Not try to evaluate everything you have written, but it seems like one of your main concerns throughout this discussion is creating more awareness of the module work that is going on and better connection between developers working on similar projects.
One small step in that direction which is very doable is a module spotlight forum in the general forum area. There module developers can announce modules they have developed or major revisions of existing modules, whether on drupal.org or not. This gives us one space on drupal.org where this information gets collated together. And I happen to think that many people will want to showcase their work.
Sure it's not optimum, but it's an improvement. One long term advantage of this is that it can raise awareness of the significance of these offsite modules and better connecting them back into drupal.org. Eventually, this might lead to a reevaluation of the module submission/CVS process that you are looking for.
So think baby steps rather than more radical process revisions.
Just my two cents :)
That's a point to consider seriously
I absolutely agree with this new method of developing. As a newby, of course!
I think you, senior developers, really need to agree with some type of developing process like the one explained here by Dub.
---
Robert Garrigos
Personal site:www.garrigos.org
Admin of: www.escolasafa.info - www.societatbach.org
Thanks robert
I agree and thanks Robert..its pretty much crucial for development because a lot of work is getting duplicated by the scattering..one developer has no blinking idea what other developers are doing.
Yes, there are developer forums and a developers IRC channel, but, outside that you have a huge scattering of drupallers developing obscenely useful modules that don't appear on the "radar" so to speak.
Unless drupallers have a lot of time to trawl through the forums, the IRC channels, google, technorati and other off-shoot drupal sites, browse slowly through the CVS repositories...it's pretty muich impossible and very time consuming for a drupaller to know whether:
* as an aside, there is nothing intrinsically wrong with the Drupal contributions process, it is complicated for a reason..as one developer said to me "if a contributer can't understand how the contributions system works....they shouldn't be contributing"...which, to me, is madness.
There should be a middle ground "in the wild" type listing of modules that are "as is" or that are "in development" alongside the contributed modules (modules that have gone through the Drupal system).
Hope that makes sense....although this thread has gotten so long, it must be impossible for others to follow it.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
You don't mean "you CANNOT develop a module w/o CVS" ?
You don't seriously mean that module developement is confined to RCS (the original one), CVS, Subversion or any of the similar versioning systems ?
It certainly helps when doing a lot of revisions or releases, but is not prerequisite, and it helps even more with the features of CVS where a lot of different developement contributors can join their efforts efficiently.
There are of course a lot of modules being developed outside any revision control system, and not just for Drupal.
I think what Dubling Drupaller meant (and others including me have agreed under several topics) is getting a better system and better inclusive system than the current one which help Drupal users finding and sorting out the correct module etc. for their needs.
If you qualify with saying "Drupal core modules" and participating in core developement, then CVS skills as a prerequisite or at least something to be familiarizing oneself with is obvious. But core modules are not the center of attention in this thread.
;-)
case in point
I had a scratch, so I itched it with a new module (http://drupal.org/node/31806) Now I have no issues with using CVS and I've applied for a CVS account (for the second time). Although I agree with others that CVS access should not be so tightly tied to a drupal-org module project. Don't know if I'll get CVS access or not but if I don't then my module will have very limited visibility. Not that big of a deal as it works great for my intended purpose but I thought I would just try to share (in the spirit of open sourceness as it were). If no one finds my module useful then so be it but I can guarantee they won't find it useful if they don't find it. Visibility through a link buried in a forum post just won't cut it.
that's a great module..
Hi Der,
Thanks for chipping in.
The control panel module is superb and a classic example of where a "in the wild" modules section where drupal users, like yourself and many, many others can just "register" their own little ditty.
It doesn't change the contributions process, but, it helps to increase the visibility of great, useful ideas and re-inforce drupal.org as a *true* community hub..as opposed to one of many sites that you might include in a google search when looking for Drupal related content.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Hey Dub,
Hey Dub,
Just as far as the audio bit goes...Colin and I did think about the existing modules available, and tried to get in touch with everybody who had been developing modules at the time. I think the goal was to replicate the amazing work that Josh Koenig did with the Music for America site, by splitting his functionality up into smaller, more manageable modules. His code was used as a code base, if not as a basis for explicit function calls, then as a basis for conceptual ideas.
Developing in such a modular way is good design practice, IMO. The reason there are probably lots of different modules for the same thing is because people want to build supermodules that work on their site. But sometimes you need something like the audio.module, which is just a really simple definition of an audio node. It could've been done with flexinode (and still can) but that would mean flexinode would have to take on a lot of added code for such a specific purpose. That means more work for maintainers of flexinode, I would think. Also defining a dedicated audio node type means that "audio" can be used as a building block for other modules (think img_assist.module and image.module).
I do share your concerns with scattering of development, I'm just not sure how to fix it. I think it is a well known fact that drupal.org is maxed out past its capacity ;)
Personally, I would like to see more formal surveys and informal testimonials about how people setup their Drupal sites, and generally how they approach webdesign with Drupal. That might give arise to a better view of what are some of the common problems people keep running into and facilitate merging of module development.
that is a classic example..
Hi Zirafa,
What you just outlined is a classic example..joshk had already created the music.module..yet you guys decided to strip it apart and release a new module instead of improving it.
Re: audio.module. I still don't get what that does that couldn't have been done by patching flexinode. And I don't understand why you just didn't improve/patch what Joshk had already done so well.
Don't get me wrong..I think the work the guys at bryght do is superb...but those who don't know how close bryght is to drupal might feel uncomfortable collaborating on a commercial project under an open source model. i.e. Bryght are developing the audio.module for bryght.com...because they need it for their new services for record labels. Not for drupal.org. There' s nothing implicitly wrong with that..but, when the commercialisation is so intimate with the open source model..I can see why some might be reluctant to patch or improve that. especially when modules already exist that could be improved on drupal.org.
I hope that makes sense..I'm not knocking you for forking joshks module and coming up with the audio.module..it's just a classic example of how the development model gets "scattered" and diluted where a culture of module "ownership" appears to be more important than a culture of simply improving drupal.org modules.
I don't agree with you that drupal.org is maxed out on it's capabilities. Drupal.org could be improved..that's a given..I'm suggesting it's more because of this "scattered" element I'm talking about.
A good example might be the handbook pages on other non- drupal sites. the beginners section on bryght.com is arguably superior to what is available at the moment on drupal.org.
the problem is that it's in bryght.coms interests to have a better handbook page than drupal.org, so, maybe more prone to improving their own handbooks rather than improving those at drupal.org
Does that make any sense?
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Dub, you misread what he
Dub, you misread what he said. They felt that the existing music for america one was to monolithic and they pull it apart to seperate out the features so they would be more accessable for other developers to add to. This is a practice that has been encouraged for the last year now. Break out the larger modules into more descrete funtionality.
As to Bryght's handbook, they have said often that theirs is open licenced. I will be stripping out some of their content soon enough and adding it to ours. Amazon (CivicSpace) is working with other folks to get modules documented in a detailed way and I am looking to see how best to integrate Bryghts stuff with drupal.org's docs so we have usability without nightmare updating scenerios.
My post was a step to starting a more generic Configuration section and I hope to work with you and others to add more to it soon. Hit me in chat or my contact page and we can discuss in more detial and get a firm plan worked out.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
points taken..
I understand what you're saying sepeck..but, I still fail to see why a working module should be broken down in that way.
The words "if it ain't broke...don't fix it" springs to mind.
It would have made more sense to tidy up joshks code, if needed, so it was available to all and then look at how it maybe improved.
Incidentally, JoshK first posted the music.module over 3 months ago. During that 3 months, following the lets-strip-it-apart logic..there is no music.module or audio.module for Drupal 4.6.0...instead we have a motley crew bag of modules, including the flexinode.module, podcast.module, audio.module, playlist.module and I don't know what else.module all attempting to emulate precisely what joshks module did extremely well for musicforamerica.org, with a few minor variations.
So, while I understand your points, I'm afraid I cannot agree...that to me sounds like a crazy approach and a monumental waste of skills, resources and enthusiasm.
Point taken about the Bryght handbook..I wasn't having a go at them, by the way....there's no need to be so defensive. I raised the thread and discussion because I care.
however, it could be argued that it's a classic example of how this "scattering" is having an adverse effect on drupal.org. i.e. the fundamental point still stands - the guys at Bryght felt the urge to develop their own handbook pages...not the drupal.org handbook pages. Even when their initial handbook pages were done and dusted.
...most contributers try something on their own sites before posting snippets/tips/patches....but when contributers stop that final step...i.e. giving back to Drupal..that's when the model falls down.
I tend to try out php snippets or tricks/other before posting on the drupal.org site. It's very rare that I would decide NOT to post something on drupal.org if I thought it would be useful to other drupal users.
As everyone and their dog knows...the Drupal.org handbook has been a real thorn in the side of the site for a while...everyone knows that.
I hope that makes sense..
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
A few misconceptions here...
Dub,
I appreciate some of your points here, but have you actually compared the audio and music modules? It seems like there are several incorrect assumptions going on here. First of all Joshk’s music module rocks (literally, in the case of MFA) but it also does many things beside just deal with audio. Many of these things are not applicable to all users. Lets start by taking a look at the schema for the music module:
create table music (
nid int(10),
album varchar(255),
stream_only int(1) NOT NULL DEFAULT 0,
license varchar(255),
process_me int(1) NOT NULL DEFAULT 0,
listens int(10) NOT NULL DEFAULT 0,
PRIMARY KEY (nid)
);
create table playlist (
uid int(11) NOT NULL,
nid int(11) NOT NULL,
weight int(4) NOT NULL
);
create table artist_profile (
uid int(11) NOT NULL,
artist_name varchar(128),
artist_statement text,
artist_url varchar(255),
PRIMARY KEY (uid)
);
create table artist_genre (
uid int(11) NOT NULL,
tid int(11) NOT NULL,
PRIMARY KEY (uid, tid)
);
create table artist_events (
uid int(11) NOT NULL,
nid int(11) NOT NULL,
PRIMARY KEY (uid, nid)
);
From this, one can see that the music module deals with playlists and audio, but also artist profiles, events, etc... This module (which I really do like by the way) was built specifically for the use case of Music For America. It is not remotely general! Imagine a case where someone might want to upload a single mp3 audio clip and podcast it. Should they have to fill in an artist profile? Of course not! What Drupal needed (IMHO) was a very simple node type (analogous to an image node) that people could then build on top of. Small pieces loosely coupled... Etc...
Here is the schema for the audio.module (keep in mind that title, creation date, etc.. are all stored in the node table):
CREATE TABLE `audio_node_metadata` (
`fid` int(10) NOT NULL default '0',
`playcount` int(10) NOT NULL default '0',
`downloadable` tinyint(1) NOT NULL default '1',
`fileformat` varchar(10) NOT NULL default '',
`bitrate` float NOT NULL default '0',
`sample_rate` float NOT NULL default '0',
`playtime_seconds` int(10) NOT NULL default '0',
`artist` varchar(255) NOT NULL default '',
`title` varchar(255) NOT NULL default '',
`album` varchar(255) NOT NULL default '',
`year` varchar(255) NOT NULL default '',
`track` int(7) NOT NULL default '0',
`genre` varchar(255) NOT NULL default '',
`comment` varchar(255) NOT NULL default '',
PRIMARY KEY (`fid`)
) TYPE=MyISAM;
Notice that this module doesn’t have events, playlist information, etc.. built in. To me, these modules look quite different ;)
Having this audio functionality be decoupled from playlists is imperative to provide flexible tools that many people can use. If you happen to need a site exactly like Music For America, then Joshk’s module would be perfect. But if you want to have a simple podcast, or sell an audio track via the ecommerce module, you are out of luck. You will need to have something more flexible. Basically Drupal needed to have a dedicated audio node type, and a playlist node type. And now it does.
Also the music module is only located in Joshk’s sandbox, not in the modules directory in CVS.
In summary:
* the audio.module is not a fork of the music.module, or any other module.
* the audio.module provides a basic audio node type that Drupal was in need of.
* It was not feasible to provide a patch against the music.module since the music.module a)does something completely different and b)is not actually a project in CVS on drupal.org
Hope this clears up a few things =)
Audio module, media module, MP3 flexinode....
Hi Dub,
I was responsible for both the media module and the flexinode MP3 field, and I've been using Drupal for media of various sorts from the start. Colin and I discussed a complete roadmap for Drupal and media sometime near the beginning of his project, and I'm really glad he wrote what he did. The other two remain as relics of the past, and for all I know the code might be helpful to someone in the future, but the future lies with the audio module. This seems like a natural evolution to me, and while it is certainly confusing to look at the list of modules in CVS and know what to use, that is more of a packaging/marketing problem than a development problem.
As for the Forward modules (the artist formerly known as email-this-page), the people who wrote it have made very nice improvments to what was there before. They could have approached the maintainer of the Email-this-Page module and asked to take the project over, but then they would have had to consider any upgrade/migration path from the old to the new (maybe insignificant in this case, but important generally), and they definitely didn't want to be tied to preserving any aspect of the old module that didn't interest them. So they made a new module. Perhaps it would be better to have done it differently, but in the end, the task now is to let peole know that the Forward module is the one to use over the Email-this-Page module.
Very often it is much easier to start from scratch than to fix or improve someone else's code.
So I think a lot of the problem is cultural - gotta help people know where things are and how things are done. Some of the problem doesn't exist (I don't see any problem with the audio module landscape right now), and there is lots of room for improvement in terms of documentation and making Drupal.org clearer, easier to use, and more workflow-efficient.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
The Agile method
To me, Drupal developement resembles the Agile developement method somewhat - http://www.agilemanifesto.org/principles.html .
That might be just an impression, but some similarities with the "good code is more important than backwards compatibility" seems to be there.
;-)
Yes, perhaps.
I've never seen anybody make that connection, but there are some similarities.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
were u ever asked to contribute to a drupal book?
A while back, I got an email from a guy who was a commercial tech-book publisher who wanted me to contribute and get paid to help put together a printed drupal handbook.
I asssume he just checked out the handbook contributers page and saw my name and took it from there...as he probably did with many others.
At the time I didn't think much of it...and declined.
Afterwards, I was thinking about how slow the handbook was evolving and that if a commercial book publisher sees the potential in printing and distributing a drupal book.....what would happen if the drupal handbook contributers all said yes to yer man...and spent their spare time compiling their bits for the pending publication....as opposed to helping improve the existing documentation.
I was wondering how hard it would be for Drupal.org to publish their own book where the proceeds (and great handbook) goes back into drupal..with enough left over to pay for a decent editor/proof reader...
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Writing books
As you probably know a book is being written - http://drupal.org/node/30035 - and input is harvested somewhat from drupal.org forums - http://drupal.org/node/29364 .
At least here you get the full discussion, while a digested form might be reproduced in the book.
;-)
It might be a bit hard to visualize a competing book from anyone within inner circles of drupal.org anytime soon - but only time will tell.
There will be more
There are several publishers looking for Drupal authors. Anyone interested in writing about Drupal stands a good chance of getting the opportunity to do so.
The "inner circles" would be happy to see more books get written, but most of the people I know who are technically capable of the task don't have time.
One of the more likely candidates to write another book is currently volunteering to do extra technical review for the book I'm writing, and I've recommended him to my current publisher, and to a different publisher. More books about Drupal = better for me and you. It all takes lots of time, though, so much patience is needed.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
I may have been but don't
I don't remeber anyone asking, but I don't see the point for me at this point. I would see proccess explanations more relavant long term then a book on a specific Drupal version.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Our handbook is under Creative Commons
Um, no. There is no spot within the current Drupal.org handbook for this type of information. It is "best practices" style stuff and "how to" stuff that I have requested again and again to have a spot for. Ideally, submitted as story nodes -- then it is clear that it is "opinion", not actual documentation (which is exactly what it is -- someone else might come up with better).
If someone from the doc team gives me the go ahead, I will personally spend the rest of the day copy and pasting every single item in our handbook onto Drupal.org. Where should it go? What section should it go in? etc. etc. -- we created all of that material before the doc team had formed, BTW.
Re: music vs. audio -- as far as I know, audio existed *before* music. (I certainly had never heard of it, else Colin wouldn't have written it). The idea was to have core audio support, just like image.
Every single thing we do that is Drupal is released back to the community. Our value is not in having better modules or documentation, it's in having a turn key solution.
let's not get bogged down..
Thanks boris..
Not that it really matters, but, you should check with Colin about the music.module...I remember trying out both and they were remarkably similar. it maybe coincidence, but...I hope the discussion doesn't get bogged down in who did what first...the key idea of open source is not the "owership" of modules or contributions, but the quality of the collaborative effort.
I understand that the Bryght ethos or business model is providing a turn key drupal solution...it could be argued that very Drupal user has precisely the same ethos for themselves and their clients/friends or whoever they are building sites for. I maybe wrong but, that's what I imagine all drupal users strive for and it's a concept that's not unique to bryght.
Either way, I was just using the handbook as an illustrative example of how a non drupal site has an arguably better drupal handbook than drupal.org...but doesn't feel a sense of urgency to help improve the drupal handbook.
It's perfectly understandable and I know very well from the last year or so how intimate the drupal developers and the bryght developers are. Drupal benefits enormously from Bryght contributions...I was just using the handbook as an illustrative example of how things get diluted...scattered...
I hope that makes sense. Please don't take my comments the wrong way..I raised this discussion because I care.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Communities
It seems online communities are a bit complex to handle, and those who handle it great make a lot of money doing so - e.g Yahoo, Google et al.
For Drupal, there are some great ideas and have been developing for some years. However, the great potential within some of these ideas are certainly not reflected in the drupal.org infrastructure - especially the forums which are technically very weak still. Drupal.org is by no means the showcase it might have been.
Traditionally, it is up to the site-admins to improve the site, and while business is booming or people gets occupied elsewhere on perhaps personal matters, things may be left to themselves a little. I'm not referring to the Drupal core code here, but the Drupal community infrastructure.
I have roughly the same length of experience like you, +1 year, and have seen mostly changes which are benefitial to me.
Somethings could need improvment, like tutorials, examples, forum searchability or a knowledgebase. Also the publication and criteria of a non-overlapping cruft-free functioning module contribution for being able to efficiently announce contributions on drupal.org seems largely unnecessary. Politics and personalities decide how it turns out when it is all volunteer based work, and money/priorities have a stronger pull on one's time.
So, it's not just splitting because of size, but because of some systemic facets to drupal.org as well, in my opinion. Community clout as mentioned elsewhere, might even drive individuals into a cycle of providing some sort of inwards-looking group-climaxing, where everyone are getting off on their utopian flawlessness and constant accolades for themselves. Thus, a seemingly loyalty from participants of this continuing process might be seen, while the more open and external breeding (or merging) of ideas is what would be healthy for the community.
Scattering seems the natural evolvement of communities which find their individual needs better served elsewhere. This a general trend, seen in news media and most other online activity, in my opinion.
scattering dilutes drupal
I agree with a lot of your points, but, I disagree about being resigned to the fact that "scattering seems the natural evolvement of communities".
I see scattering as the demise of a community.
Think about it...isn't the whole idea of the community concept to be the opposite of scattered?
Is it so difficult to enable blogs for veteran drupallers...So they can start their drupal musings, hacks and development ideas at drupal.org rather than drupal[insert variation].org?
Wouldn't drupallers who have created their own quirky or useful modules for whatever reason be encouraged to post their "orphan modules" or hacks in a drupal.org blog rather than setup a completely different site?
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Scattering definitely dilutes the community
And, new people who have good ideas (or even just ideas) should be encouraged to contribute.
New contributions from varied sources will help spark ideas and approaches that will eventually prove useful -- even if the original contribution was sub-optimal. I know it's a cliche, but the whole is frequently greater than the sum of its parts.
Separating drupal projects into three sections -- core, tested modules, and untested contributions -- would allow new ideas to flourish on drupal.org. Core developers, or some subset of the community, could move projects back and forth between categories (ie, from tested to core, or from tested to untested) as circumstances warranted. So, if a tested module isn't maintained, it gets bumped to untested, etc.
Voting/rating would also be helpful in sorting out reliable from unreliable modules, particularly among untested modules.
In short, most of these issues seem more related to organization/site structure. With a clearly defined structure, it is very possible to simultaneously support inclusion AND maintain high standards for clean code.
Cheers,
bonobo
-------
http://www.funnymonkey.com
Tools for Teachers
-------
http://www.funnymonkey.com
Additional thoughts on modules
Seems to me that modules fall into one of four different categories.
1. Core modules - [obvious] these are the modules distributed with Drupal. They provide the core functionality of drupal. They have gone through the most scrutiny with respect to functionality and adherence to drupal best practices.
2. Drupal.org Contributed modules - these are drupal hosted modules that have been deemed worthy as providing some useful benefit to the community at large but do not duplicate the functionality of an existing hosted (or core) module.
3. Other Contributed modules - these are modules that the authors have offered to the community but are not hosted on drupal.org either because they failed the "worthy" test described above or maybe the authors never pursued the Drupal.org option. It may also be that it's a module that lacks a strong commitment by the author to support it long-term.
4. Other - Modules for some reason or another have just not been offered to the community by the author.
I don't know how many modules fall into category 4 but my guess is that the majority of the modules fall into category 2 and 3 (maybe 40-60 split?) These are the modules that I believe need to be represented in some kind of common repository. Access to accurate and complete module information is what's important here, not where they are hosted. When someone comes across a new module that isn’t listed in the repository the first course of business should be to get it listed so that the community knows about it (and can benefit from it). The bar should be fairly low for getting a new module listed; otherwise people just won't go through the effort.
I believe this type of central (compete) repository is essential for the continued growth of the drupal community.
again, just my 2 cents.
I'd say there's one other
I'd say there's one other category of module...
5. Abandoned modules - Modules that have been left behind by their authors and Drupal's "break early, break often" approach to compatability.
For the poor user of Drupal, it means that if you use any modules that aren't part of the core distro, you run a high risk of getting stuck using your current version of Drupal because there's no way to upgrade your old module. As Dub said, "uncertainty about whether you should install a.module or b.module or c.module and which will be maintained."
On the development side, it also lends an element of time to the duplicate modules problem. Someone considering writing a module to gain certain functionality may not even realize that there was a module for an old version of Drupal that provided that functionality (and maybe more) that just never got updated to the current version of Drupal.
An excellent idea that's partially implemented
If you browse the download section of drupal.org, you'll see a 'modules' section. This list, by default, is filtered by core compatability.
Perhaps a more obvious distinction should be made between old, unupdated modules, current-version-compatible modules, and under-development modules that are not yet flagged.
--
Eaton — Partner at Autogram
Sure, but that doesn't solve
Sure, but that doesn't solve the problem of the user not knowing if a module they want to use is actually going to be updated when the next version of Drupal comes out, or the version after that...
There's no way to know that period.
If a given user isn't able to code, or isn't able or willing to contribute patches to update modules, they will always be at the mercy of version updates. This is true of Drupal, Photoshop, Mambo, MovableType, and Windows.
I don't mean to shoot you down, because I think the problem of finding the right information on the drupal site is an important one. But there's no way to offer what I think you're asking for, without signed contracts requiring module developers to update their code every time a new version is released.
That's one of the reasons I think a division between 'experimental' projects, 'personal' projects, and 'supported' projects is important. If I pick up one of the first type, I know I'll just be using it as a besis for my own development. If I use a module in the second category, I can be fairly certain it will require tweaking and code customization for my site/version of drupal/etc. If I use a 'supported' module, I can assume that there are people working on keeping it in sync with the latest verison of drupal and integrating third-party ideas for fixes and enhancements.
--
Eaton — Partner at Autogram
Of course there's no way to
Of course there's no way to know that. But that doesn't make it any less of a problem. As for your comparisons to Photoshop and Windows, the difference is that you're looking at at least a good 5 years of backwards compatability with Windows, versus only about 6 months for Drupal.
Still, your division of projects idea is probably a good one.
This sounds me to Debian
I'm just too new to Drupal as to Debian, but this post makes me think on Debian and its branches. Which I like.
If I'm posting here is because I'm just in the position that Dublin is 'criticising' (Don't get me wrong, Dublin. I know you have very good intentions).
I'm developing a new module for a third party based on the ecommerce module. I'm not developing a patch for it because I don't need an ecommerce module with some new features but an ecommerce module which works slightly different. Now my position is that I would like to give back some of the effort other developers have put in Drupal, which is helping me to make some money to live. However I don't have a patch for a module but a sensible different module. Or, like Dublin says, a module that does the same thing in just a slightly different way.
In this case I won't be able to commit my module to the Drupal.org site. And here I come to my point: I agree I shouldn't be able. I like the idea of having a list of tested modules (fully tested and fully documented with their compatibilities/incompatibilities) and another list of untested modules. They could even be fully tested but shown on a different list because of their similarity with other more 'general' modules. This means having 'branches' of modules acording to their more or less general functionality. Maybe also according to their needs of core code patching. This way new users to Drupal could relay on having a farily secure set of core modules with the option to 'upgrade' to more complex modules with more technical needs. And here I'm thinking of i18n.module, which I couldn't live without it - many, many thanks Jose! - but which needs some core patching though some more technical knowledge.
I think this will help other developers to post their works to drupal.org and help to grow the drupal community rather that scattering it.
---
Robert Garrigos
Personal site:www.garrigos.org
Admin of: www.escolasafa.info - www.societatbach.org
Add options?
If it's the same module acting slightly differently, why couldn't you implement the changes as extra options? I've hacked in hardcoded changes as stopgap measures myself, but if you want to contribute the thing, just go the extra layer and add the appropriate config option.
In fact, maybe there needs to be a place to dump "Hacked modules needing their hacks converted into config options," so if you're not intimate enough to code that yourself, you're at least getting your change out there for someone else to come along and abstract out.
Why is a forge site not good?
Too many options and you may find yourself with a six fingered bowling ball.
Probably not helpful or useful just funny.
But why is a forge site not good? Many of the other opensource cms projects use them sucessfully.
This site IS Drupalforge.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
I guess I don't get it.
I guess I don't get it. Because most forge sites that I have seen are open without checks. So I guess I am saying whats wrong with having a more open forge type site. Or Maybe something like "freshmeat"?
How about...
"Freshdrips"? :P
Scattering is bound to happen
Drupal.org doesn't pay people and many want to earn money with Drupal, which is good. One way to earn money would be to have a Drupal documentation site with original documentation, tutorials, reviews, etc., and Google ads. This clearly can't be part of Drupal.org, is very likely to happen soon, and will be good for Drupal in the end, not bad for it.
Google and other search engines make the problem of scattering less problematic than you assert, and I'm personally not worried about it. I use technorati, feed readers, Google news and a bunch of other sources to keep my finger on what is being written about Drupal, yet I never feel I'm leaving the community when I visit individuals' Drupal sites.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
that's a given, Robert
with the growth of Drupal and the spread of contributers, scattering is inevitable. That's a given. That's not the problem.
The problem is the community hub is being scattered...
The forum, handbook and generally everything to do with Drupal is community driven. It's value and strength is based on that community. And conversely Drupals weakness as a project is intrinsincly linked to the community and how that community interacts.
the handbook is relatively weak and shows no signs of improving.
Why?
Because it's more important for offshoot sites to improve their own drupal documentation than it is for them to improve drupal.orgs docs.
because drupal.org is no longer the place for the community to gather..choosing to go elsewhere or to an IRC channel to communicate. It's losing it's asset value as the community hub and as a domino effect, it's losing contributors.
the forums are dreadful and turning into a place to avoid for veterans
Why?
Because it's much easier for many to go to another site or IRC channel and discuss, debate, ask questions on non-drupal.org sites and therefore the whole "knowledge base" aspect of the forum is redundant.
How many peoplpe do you know who use google to search drupal.org rather than drupal search? Or how many people do you know use technorati/other instead of drupal to keep up to speed with what's going on?
drupal development is uncohesive, scattered and in more and more cases, very wastefull
Why?
Because there is no longer a defacto community hub for Drupal, it's impossible to know what's going on without jumping through IRC channels, google, technorati and a suite of other offshoot drupal sites and simply sites that have sprung up talking about drupal.
I've already mentioned the crazy situation we have with the emailthispage.module and others.
You say because we have google we shouldn't worry about scattering. I couldn't disagree more. just have a look at the forum, handbook or the contributions page on drupal.org.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
the handbook is relatively weak and shows no signs of improving
LOL
We'll, I would think that the Drupal docs team would beg to differ there. Seems a strange comment, too, given all your work with php snippets. There's been a lot of improvements in the past year, much more than in recent years past.
"Because it's more important for offshoot sites to improve their own drupal documentation than it is for them to improve drupal.orgs docs."
This might have been the case a year ago, but the documentation team has been working to integrate things offsite into the handbook.
lol...
I see your point cel....perhaps I'm not being clear.
The main thrust of my point is that Offshoot sites and handbooks are growing faster than drupal.org's and the general scattering of the drupal community hub is hurting drupal.
An offshoot site is different from a "fan site", where a products popularity helps the spread of little microsites around the web.
Fan sites are good for Drupal. Off-shoot sites are bad for Drupal.
The reason is because the drupal handbook, forum and development is reliant on the community.
Once that community scatters, it dilutes the community, confusion reigns and development turns into a my-module-fest nightmare.
I hope that makes sense..as an example, when I started the php snippets page...it did cross my mind to setup my own mini site away from drupal.org and just link people across. giving myself a chance to build my own mini drupal community and maybe attract some work that way.
It didn't take long for me to realise that while doing that would be great for me, it would be detrimental to drupal.
I hope that makes better sense....
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
we'll just have to disagree
we'll just have to disagree somewhat on this one :-)
the biggest problem with the handbook right now is that it is growing very rapidly, much faster than we have people to work with the text that's in there. look at the number of pages that have been added this week and the number updated. then consider all the comments that need to be integrated back into the text and deleted.
now there are definitely some people maintaing documentation elsewhere, but i know that many of them are also working on the handbook too. i think your talking about the exception rather than the rule. if anything, our problems stem from too many people needing and wanting documentation, but not that many willing to write, revise, update, or edit any.
one other thing
one other thing that occurred to me is that the concept of a large, organized documentation writing effort is fairly new to drupal. right now there may be people offsite creating documentation, but creating and maintaing documentation is just as difficult as doing the same with code. it's much easier to do it collaboratively on drupal.org than by somewhere else. you'll see people drift back in with some stuff when they figure out it's a pain to update it each time for every new version release.
Scattered communities
I don't think a community is the opposite of scattered itself. Actually, there is a whole discipline under computer science (specifically system development) called CSCW - Computer Supported Cooperative Work. The idea is that technology breaks down the typical separating barriers. An extreme variant bloomed when the dot.com was on it's frenzying height - virtual organizations - like e.g featured in Fast Company magazine et al. I even founded one such company, which was fun.
Your idea of "veteran blogging" to get more free-flowing ideas with some experience - small "guru-centers" - is very good. That way, more effort might possibly be put into growing and interacting the community.
Nothing comes without change though, and currently there is a seemingly very rigid reign on drupal.org. Could you imagine blogging about your professional services on yoursite.com while giving free expert advice via your drupal.org blog, without the stringent control like displayed on http://drupal.org/drupal-services and http://drupal.org/services ? Do you belive the list is "automatically generated" as claimed there ?
I do agree fully on the "being enabled" approach, instead of the "being led" herding approach. When everyone is getting financially involved there is better with transparency and full honesty, instead of limiting the possibilities.
Also, the question about carrying the copyright statements seem to be rather dissatisfying with the current model adopted by drupal.org. It seems patches or contributions (modules etc) "gets taken over" - prettyprinted or otherwise changed - and then anonymously incorporated. Perhaps that is not how everyone sees it ?
Some are against unnecessary cruft with the overflowing of module contributions - same for patches. Obviously, some central packaging is needed, and some quality-control measures to keep current as well. But then think about the Drupal development system - without strict APIs - where everything can and will change, there will be unavoidable situations where a contribution is no longer applicable to current core release. Then the community need some form of control/rating like you mentioned, to inform others.
Currently, drupal.org lacks these things. There are a few cooks, and they're pretty much busy or seems not to be able to commit fully.
If you have the experience of "outgrowing your current business", where you need to decide on "stay small" or "go for it" - you reckognize that a lot of effort is needed - not half-hearted attempts. It takes a lot of work, and if you can't delegate or coordinate but prefer to do all the work yourself, you're eventually going down ...
pedantic note: you're confusing "distance" with "scattered"
without digressing down a pedantic route too much..I think you're confusing the concept of "scattered" with "distance".
A community thrives around a hub. Not a collection of individual, often remote and unkown mini-hubs that just shares a common code base with drupal.org.
My point being that the general "scattering" of the drupal community will have a domino effect on drupal long term...for example, already we are having these funamental problems:
As an aside, I took part in an online discussion via drupalart earlier today..which spawned this thread..Drupalart is an excellent site that was created as a place for artists & creatives to discuss how to use drupal in the creative sector.
Instead, it is now, mainly, a development hub for creative sector related modules. I'm not knocking drupalart.org...I'm merely using it is an example.
I thought it would be worth flagging and discussing because the core developers and drupal team wouldn't notice it. They are busy enough as it is working on drupal 4.7 to have time to google out non drupal.org sites to catch up on what's going on.
When I realised that there are now 6 or 7 modules doing very similar things (music.module, audio.module etc. etc.), it just struck me how messed up it has become and how potentially disastrous it could be for drupal long term...
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
I was not completely clear ..
I actually also meant to include "scatteredness" better in my response, but it sort of fell out of my memory lapse ... ;-)
I feel that an online website can "huddle together" scattered parts of a community by itself - without any effort on behalf of individuals.
Examples of this are tucows and other shareware sites. Other examples are in abundance.
The scatteredness itself can certainly impose practical problems for users searching out information, but not insurmountable problems which can't be solved by someone deftly structuring a common meetingplace. Ratings and finding out what is being supported - and perhaps even more importantly - what modules are being used and how are they being used - can certainly help remedy the information problem.
There has been talk of how a directory like this is missing from drupal.org and that the obvious route is that someone compiles such a site, gives it powerful community rating and reviewing functionality, put in Google Adsense and make some quick bucks.
;-)
I'm not avoiding your point about the forums and various meetingplaces, and how they might prove challenging for newcomers. Rather, I take a different approach and see it as an opportunity for someone to provide something which is better than drupal.org - gathering the bits of information without all the red tape bureaucracy from drupal.org maintainers.
If it is a bad thing for Drupal, I don't know (time will tell), but there needs to be change and effort to be able to handle a much larger diverse community.
Red tape bureaucracy from drupal.org maintainers?
Red tape bureaucracy from drupal.org maintainers.
What are you referring too? Can you provide concrete examples?
Module contributions, CVS account criteria, drupal-services ..
.. was what I was thinking of. It has been confirmed that contributions will get very little visibility if they are not listed on the general contribution listings.
Several have mentioned, Robert Douglass included, that there might be someone making soemthing like a Drupal-forge website listing alternative modules not seen fit to be included on the drupal.org listings.
;-)
Still not clear ...
It's still not clear to me.
- What do you mean with red tape "module contributions" bureaucracy?
- What is wrong with the CVS account criteria? Please be specific. CVS accounts are being reviewed periodically. Over 300 Drupal developers have a CVS account ... I don't think any of the other FOSS CMS projects have that many. Are you familiar with CVS, and the implications of giving people a CVS account?
- The Drupal services page is free for everyone who contributes to Drupal. As mentioned on the services page, you can get listed by sending an e-mail to the developer mailing list. Did you check the developer mailing list archives to back up your claims? Can you point me to people that have not been added, despite having followed the instructions?
Hehe
It seems some modules won't get included in the list because they can't get that camel through the eye of the needle, they don't make the cut because some voice opposition to inclusion of a module.
A concrete example most recently here: Acidfree.module - How do I get my module into the contribution tree?
If that isn't a red-tape, I don't know...
Listing a module on drupal.org should not have to imply a CVS account, that's just silly and a relic of old times. New-times-drupal.org should have a wider horizont than that, and be more open minded. Of course an author should be able to offer download on drupal.org or his URL of choosing, but drupal.org would probably mean better availability over time. Incidentally, I've used CVS for years - since around 1988. ;-)
http://drupal.org/services says the services-list is compiled automatically, but someone on the list said it actually needed approvement to get on the list. The short list speaks pretty much for itself - http://drupal.org/drupal-services .
The other list on http://drupal.org/profile/drupal-services is a bit more anonymous, and doesn't make much sense how it is sorted (or ranked?) it seems. I was more going on memory from http://drupal.org/node/30217#comment-53785 .
not a bad idea..but..
It's funny you should mention Robert..I notice his signature (apologies if I'm mixing you up with someone else Rob) on drupal.org links across to his site to "Vote if you found this post useful"....and when you click across, you have a wealth of tips, tricks and drupal blogs that are one of those that automatically go into the bookmarks.
I actually like the "Red tape" thing you're talking about...it's comforting to know that it's not easy to get a CVS account and anyone after a few months with some savvy contributions to the forum can worm their way into getting CVS permissions.
I also like the idea of drupal-forge..the only drawback is who is going to maintain that..
I think it would be much simpler if veteren drupallers maintained their own Drupal muse blogs on drupal.org..instead of setting up their own and inadvertantly diluting the drupal community by scattering knowledge.
incidentally, the majority of those non drupal.org sites I'm talking about tend to use default, out of the box themes, with Zero changes..which suggests that they just wanted to keep a drupal blog.
veteren drupallers blogs on drupal.org would help remove the need for a drupal-forge type setup...i.e. the blogs would contain announcements such as "I just made a little module/widget that does [insert functionality]...I'm not going to release it on drupal.org, but in case anyone else is interested..click here" or "I just hacked the [insert name].module to do this [insert thing], but I don't know how or have the time to make a patch..click here"
That way, we maintain the status quo CVS which is what the core drupallers like and know...while at the same time, there is scope for others to keep in touch with what's going on and drupal.org turns into a *true* drupal community hub as opposed to a place where veterans avoid because of newbie questions...or other reasons..
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Agree
I don't think CVS access to core Drupal should be given to many developers, but to those active who need it and it makes sense to have it.
But listing a contributed module, should not require a CVS account. That's a drupal.org infrastrcuture flaw which drupal.org maintainers could fix.
The veteran-blog is just a very good idea for many reasons, including commercial services etc.
Who knows, maybe drupal.org will be banners-driven in the future. ;-)
Drupal blogs
You do know about http://drupal.org/planet, right?
You can keep a blog anywhere, using whatever software, and it will automatically display there. Khalid has been very good about announcing snippet releases on his blog, and then linking directly to the handbook entry. I recently did the same thing with the settings for Photon.
I do now Boris. thanks
Just clicked on that for the first time..
thanks.
The page looks dreadful in explorer...but, the content is precisely what I was thinking of.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Looks a bit dreadful in
Looks a bit dreadful in Firefox too. :P
Did the content of someone's post break the layout or something?
Also, while I did know of the new Planet Drupal, where the heck is this linked from on the site?
Just to be clear
I don't promote a Drupal-forge site. I raise it as an example of what will happen if we don't succeed in finding ways to include everyone's efforts.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
good points
I see what you mean..although I can understand the red tape element when granting CVS accounts...I remember reading about a php "hole" or exploit in one of the most popular php based forums a while back that created a bit of a furore. I can't remember which php forum it was that was hit..but from what I can remember it was a contributer who deliberately left the Microsoft Orifice styled hole in there to do damage.
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
The profile list is automatic
This list is automatic and based on your profile page:
http://drupal.org/profile/drupal-services
The links you posted are not automatic.
As I test to see if there is a Cabal blocking people, I encourage anybody interested in being on those lists to follow the directions and ask to be included. If anyone gets excluded, please report back and let the people who did the excluding defend their decision.
My own understanding of the services lists is that they include everyone who has demonstrated the ability to provide services AND has asked to be on the list.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
You have voiced all of my concerns/frustrations
Hi,
I am relatively new to Drupal, recently converting from Mambo. I have fallen in love with Drupal and all that it offers, but am extremely frustrated with the lack of organization and scatteredness of the modules and the community.
It is always a hit or miss situation to find out about new modules or updates to existing ones. And, then trying to figure out which ones work for which version of Drupal, which patches need to be applied, which ones are still being developed, etc. It is a mess. Having to constantly scan the recent posts to find out this information is frustrating. And the search function on drupal.org is almost pointless. I end up using Google to find what I am looking for.
I have not felt supported by the community since arriving at Drupal. I also just found out about the IRC channel, but have no intentions to go to IRC for support. I prefer well organized, well used, and easily searchable forums so that I can gather information when I need it, not when someone who can answer my question happens to be on IRC. I've noticed that many questions on the drupal.org forums go completely unanswered.
I am spending way too much time hunting after answers to my questions rather than doing actual work on my sites.
Blue Cobalt
Theurgy Foundation
http://www.theurgyfoundation.org
Blue Cobalt
http://livingparadise.org
Conscious living for a better world.
Ditto 100%!
Ditto 100%!
I am amazed at the number of modules I find that are not hosted on drupal.org. I am also amazed at the number of modules I find in the contribs CVS that are not listed in the drupal.org modules. I understand the need to have and enforce some standards for what projects are hosted on drupal. I also understand that many of the modules in contrib might not be ready for prime time, thus are not listed. But this makes finding a particular module to meet your needs very very difficult. I very often find myself trying to find a particular forum post that referenced the non-hosted module xyz.
I think drupal.org needs to host a module repository that can include hosted AND non-hosted modules. The repository should allow user voting and commenting. The repository should be easily sorted/filtered by rating, most downloaded, release levels etc.
just my 2 cents.
Guilty
These are all great points. I must say, however, that I'm one of the people who generally find it much easier to write a new module than to alter/patch somebody else's...especially for smaller modules. It takes quite a bit less time to create a new module than it does to convince somebody else to accept your contribution/patch to their project. I'm also guilty of developing a module for a particular project, contributing it to Drupal, then neglecting it, as the site that it was implemented for doesn't require any improvements. I have created several modules that haven't been very well maintained due to time restrictions. I tried to encourage others with more time/interest to adopt these as you may recall.
I haven't really kept up much with the community over the past year or so, so I can't really speak about that scattering issue or social politics, but I have personally put out queries about functionality, found no existing solutions, developed something new, only to find out that something similar already existed. As it turned out, the description of the module I duplicated wasn't particularly well worded at the time and I looked right over it. I'm guessing this is not an isolated incident. Now, multiple modules exist in that area that do similar work. They've branched so far apart that they are distinct solutions to a similar problem. Thus, they all still exist.
It seems that the module with the most support is the one that survives to the next release. Is this module Darwinism at work here?
Funny you should mention Darwin
What does he say about the continued survival of the floppy disk?
Carcharodon carcharias is an example of a species that defies evolution. It predates calcified bones but in a fight it keeps up with modern species. It is an endangered species worth saving but you do not see people going out in to the wild to pat them. Although Carcharodon carcharias is happy to get up close to humans, you do not see many greenies hugging Carcharodon carcharias.
Carcharodon carcharias has a family history going back 455 million years, which is 225 million years older than dinosaurs. Carcharodon carcharias must be at least as old as Unix.
Perhaps Carcharodon carcharias can be compared to modules that are ignored by most Web site developers but have great impact on a small number of sites. Individually those modules may be unpopular, just as Carcharodon carcharias is at a pool party, but collectively they keep the Mambos and XOOPs away.
Carcharodon carcharias:
http://www.poc.it/stories/desktop/desk_1024/shark1024.jpg
http://www.brunsonimages.com/gallery/Great_White_Sharks/great_white_shar...
http://petermoulding.com/technology/content_management_systems/drupal/
petermoulding.com/web_architect
Perhaps...
What we need is set of classifications for modules, even projects.
Experimental
Tinkering, proof-of-concept, and group-development projects that are of interest to the greater Drupal community but should not in any way be considered supported or ready for prime time.
Contributed
Modules and code designed for use on a specific site, or for a specific project. These may require goofy patches to core, or require custom tweaking to work with different sites. They work, but will probably only be changed if the original author needs to 'scratch an itch.'
Maintained
Modules and code designed to run against a clean Drupal installation (or clean + specific other modules). These are supported and probably have several people contributing to them.
I'm not sure about the category names, but does this sort of division make sense?
--
Eaton — Partner at Autogram
I would like to see something like this
http://www.cpgnuke.com/Downloads_9x/c=2.html
Where there is a certification on modules, reviews and poularity ratings.
I would also like to see member rankings so that I can know who I am talking to on the forum. Are an admin, mentor, moderator, core developer or a humble newbie like myself. I come back more often when I can see that there is someone in the top levels helping those that are just getting started.
Module Fork
I am guilty of forking one module. This was due to the fact that the patches that lead to the fork already existed but were not committed. I went ahead and applied the patches and got a module out of it. Now I saw that people were in need of my forked module so I released it into the wild. I think if more commits are made via the patches and the end-product with a quick adoption cycle I would not do such things... But that's being a bit too idealistic, I do think fragmentation is to some extent a hallmark of a modular system where people are free to do as they want in terms of developing and publishing their code. Should there be a culture of consolidation, perhaps, but so far I have had my cvs application rejected 3 times, 2 of which I thought were valid... So there it is.
--
Please read the handbook, search the forums, then ask...
http://drupal.etopian.net (Modules and Drupal Services)
Scrap the mailing lists while you're at it
Once upon a time, Drupal development and support discussion was going to be "moving away from the mailing lists to the forums". But as of now, that hasn't happened.
Why?
From where I'm sitting, it looks like pointless redundancy. As if it weren't already hard enough for new users to find answers in the forums through the search, the mailing lists essentially exist in their own little worlds, completely unsearchable by the little box at the top-right corner of every page here. Dub said he went about a year before he even learned that the IRC channels exist. Do you think it's any different for the mailing lists?
If you really must have e-mail access to these discussions, then build an e-mail gateway to the forums. Existing 'subscribe to this forum/thread' functionality could probably be used as a base. Ideally, you'd also import the archives of the list into this forum, bringing the existing body of knowledge/discussions into the rest drupal.org.
Keep the discussions in one place, and make them useful to the general user.
Where is this? Tell me Please!
I have been looking for a week and have not found a subscribe button.
Well let's see...
Well let's see...
There's the Notify module...
Or the Signup module...
Or the Subscription module...
Or the Subscriptions module...
Oh wait, you mean you want something that can be used here on drupal.org? Sorry, as far as I can tell, none of them are being used here.
Yeah, four modules that do the same sort of thing? This is what Dub is talking about with development being too scattered/uncoordinated...
There will be another, as well
I think Bryght is sponsoring the development of another subscription module. Who said choice is bad?
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
In this case, I do. Give me
In this case, I do. Give me one good module over having to sort through half a dozen mediocre ones.
I second that emotion...
I totally agree Toe...Toetally even! (sorry. couldn't resist)
The situation where we have 5 or 6 modules doing essentially the same thing is madness.
That dilutes the skill base, expertise and multiplies maintenance duties by 5 or 6.
I can understand the logic behind there being tinymce.module and a htmlarea.module, where there are very valid reasons to have different versions.
+ 1 for having 1 or 2 brilliant modules, rather than having scattered development, confusion and multiple modules doing the same thing.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
developer-only mailinglists
I think they serve their purpose to avoid "how do I"-type questions by Joe '0-hour-user-of-Drupal' Average. That way you can get work done without having all the nagging, whining etc.
If that's the right approach or not, I won't say. Some developers and organizations deploy first line support, second line etc. to not swamp their developers. That's just a reality.
The maintainers behind drupal.org perhaps have too little workhours to put in nowadays - because activity is certainly growing in the forums.
And like first stated in this thread - a typical new Drupal user face around 80% of his time bewilderingly looking for answers, and a small portion on actually getting some work on his site done.
Maintainers
The maintainers behind drupal.org perhaps have too little workhours to put in nowadays - because activity is certainly growing in the forums.
What work do you expect the maintainers to do? The maintainers fix drupal.org related problems that are reported using the contact form or using the infrastructure bug tracker. See http://lists.drupal.org/archives/infrastructure/. The maintainers don't necessarily provide support, although many of them do.
Some improvements or changes ...
Enabling "power-users" to contribute and making it worth their while is always a great model for success in my opinion. Dublin Drupaller mentioned a way to blog about solutions in a central place like drupal.org.
That is a very good suggestion which even can incorporate benefits for professional designers - where they can tout their services too, and not be scrutinized by the "automatic inclusion" onto the http://drupal.org/services listings under support.
;-)
I don't think it's possible for the drupal.org few to answer all the questions, nor make all the tutorials needed etc. The rate of module contributions etc. makes it far too fast-apced.
A good look on how to enable more or better contributions would be a good start. The forums themselves are not improving a lot technically from release to release, so better look at other means.
What are you talking about?
What are you talking about? Anyone can answer questions. Well, anyone with an account. No one is paid to answer questions. You can answer quesitons. No one is stopping you from answering questions. Drupal_Dublineer is a site maintainer and he contributes to the site, he contributes to the handbook.
Anyone can post handbook pages. They go into moderation queue and then get approved over time. How can this process be made better if ANYONE can ALREADY do it?
Anyone can write configuration guides. However, no one person can do it all. I kept thinking I would get around to it, but never did, so I asked the community to help. Lot's of responses. I hope to use them as the basis to start a configuration guide in the handbook.... You're right, no few people can do it all. Where's your guide contribution here?
You want the forums to improve, then get cracking. We so far don't have 'Yet another unpaid volunteer' that has actually started work. I know someone that hopes to start work in a month or two after the freeze, but she is busy with documentation and helping with module forms conversion with the current HEAD version in preperation for 4.7.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
So you want to hide the
So you want to hide the developers away from the unwashed masses. Whatever. So why even bother having forums for development/infastructure/etc?
And that still doesn't really justify having a completely seperate mailing list for general support.
THe drupal-devel archives
THe drupal-devel archives are open to anyone. Drupal devel list is open to anyone. HOWEVER, the list is specific to development questions. It is also subscribed to the drupal project tracker so is a high traffic list. Avg slow day traffic can be 40-150 messages a day.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I meant that more in context
I meant that more in context of the post above. I know the lists are public. But you've gotta admit, not having their archives searchable by the main drupal.org search box probably makes it a lot less likely that the average user will ever find the info they contain, which may be useful to them. Remeber, we're talking about the support mailing list too, not just devel.
If a user wants to search through the documentation and support discussion archives for problems like theirs (and isn't that what we want people to do before starting a new thread?), the first place they'll go is to the search box up at the top-right corner of the page. From the user's point of view, you would expect that using that search box would search through all of the information available on drupal.org. But as it stands now, it doesn't - the user won't find any of the info from the mailing lists.
You and I know why they won't find that info in their search - the mailing lists/archives are essentially a totally seperate system from Drupal. But step into the user's point of view for a moment and ask yourself: Is having this seperation in any way useful to the user?
As for the development lists...
But isn't the same true for the development forum? A new user could post a support thread to the development forum, but they could also send a support question to the development list. At least with the forum you could move it over to the proper board. As with the support list, I just don't see what the advantage is to having both the development list and the development forum. And if one is to be killed off, I think it should be the mailing list.
For some things, a mailing list is fine. A daily digest of CVS commits, the newsletter, security bullitens - these are all great things to use a mailing list for. The key difference here is that those are one-way notifications - not discussions!
To put it another way, for any discussion about Drupal, doesn't it make the most sense to use Drupal?
ah, ok.
ah, ok.
Virtually every actual issue is discussed in the project module comments. The mail list is a great way to read those comments without having to track each and everyone of them, you then respond in the issue which kicks out a one way email so you know you have to go look at something. Most actual Drupal-dev discussion involves fluid items and directions that then get moved back to Project issue tracker for implementation. If you look through the archives, you will see that for the most case (I am making generalizations here).
Last, we'd need buy in from all the current key devs. :) I don't control that and don't thing anyone actually does. The vast majority of stuff is actually tracked on Drupal.org in forums or Project issue's and patches.
As to searching mail lists, well, you're right. I don't have a solution for you.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Mailing list / forum integration only happened recently
It has only been in the last month that the mailing list to forum integration has been good enough that one could actually use it. If you want to try it out, download and install the latest version of CivicSpace. I think Drupal people chose Mailman for the lists out of time considerations back when Drupal was still very young. Perhaps in the near future we can move to the integrated forum mailing list approach so that mailling list is better integrated into the site. Once again, it is a matter of time and resources.
Since I've mentioned CivicSpace, I should also point out that they have been perhaps the biggest generators of new Drupal code in the last year, and it is all hosted here at Drupal.org. They are "scattered", but still core to the community.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
Maybe this is not my place
Maybe this is not my place to post because I'm a drupal newbie. But I can definately agree that this last week in using Drupal has been very frustrating. The handbook is less than adequate at explaining everything I'm interested in learning about. Ok.. so I went to the forums, but had no luck. A large portion of the posts are old, and didn't seem relevant to my version. So, I post new threads. Which may or may not get answered. I wait and watch.
Under specific modules, I've been trying to search for answers to my questions, but also often without results before posting my own question. Which again, may or may not get answered. I usually give up and try to figure it out on my own and modify the modules to suit my own purposes or abandon them altogether. Maybe I'm just too inpatient to wait a week for an answer.
In other developement type forums, the answers typically have been much faster. I don't know why, but something about the interface in drupal is just not quite as easy to navigate.
- Just the view point of a newbie who had no clue about the IRC or the mailing lists until now (although I prefer the forum since it's easily accessible from the many computers I use each day).
you're comments are very welcome..
There's no need to tip toe around ryooki...Your comments are very welcome. Drupal is great, but, it's difficult sometimes to suggest ideas or discuss objectively when so many have their own point of view about how things should work.
I agree, by the way, the drupal forums are clunky, but that's a work in progress and I have tossed in my two cents below.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
This is part of the reason
This is part of the reason why I favor consolidating as much discussion as possible into the forums - it's the most universally accessible. As for the forums being clunky, well, let's just say I've said my peace...
Yeah, I hate being tipped around! :(
Solutions?
* confusion about which modules are which, what difference there is between modules that do the same thing
* uncertainty about whether you should install a.module or b.module or c.module and which will be maintained
How would you like to learn about the difference between different modules? Reviews? Comparison charts? Screenshots? Discussions?
* You find it frustrating to get quick responses from the forum and don't know about the IRC support channel
Information about the support-channel is one click away. Just click the support-tab.
* You learn about new developments or essential fixes by visiting drupal.org and spotting posts by chance while browsing the RECENT POSTS.
What solution do you suggest? (I'm going to setup the simplenews.module on drupal.org later this week. We're going to use that to create a security-announcement mailing list. More about that in a day or two.)
Security-announcements etc.
Just a sidenote to that: remember that secret security-fixes and security-discussions do nothing if there is no secret CVS-repository. Clever hackers know how to browse through CVS-fixes and find the exploits.
The response from Moshe to the XSS node-title false alarm made me remember that (he mentioned the special security issue reporting); just to not let the effort itself be in vain.
Of course this makes maintaining a CVS repository all the more complex and demanding wrt CVS skills for those "lcuky ones".
;-)
What are you talking about?
What are you talking about? There is no 'secret security' fix stuff, no secret cvs repository. Currently when the last one hit, we realized that there was no security announcement mail list, so the announcement was sent via the newsletter subscriptions list, posted to the front page and announced to at least one major security bug tracker.
It was decided to create a security announcement mail list as wel for future issues. There was added a team and a Security Contact form for individuals to report security issues and that is monitored by some folks.
In the mean time, the server move has been going forward and folks have been working on things.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Security
If you'd like some sort of security-handling with regards to software developement, you'd like to receive it "silently", not publicly touted in a forum with exploits and all ready for the world to see and script-kiddies to find in some root-kit or similar.
Now, with a "secret" announcement, you can contain the information, fix the problem in question - preferrably using a secret CVS repository - if it's public software, and hopefully you can release the nest version without any users of your flawed software being affected or exploited.
Now, if you have "secret reporting", but no "secret repository" for the fixes, some hackers actually are clever enough to know about CVS too - not only white hats use these tools - and they can quickly figure out what a CVS commit is doing.
If you still don't know what I am talking about, you could take an interest in reading something like bugtraq - one of the fastest breaking lists out there. You will find a whole world of interesting stuff. There are some english-language russian-hosted sites which are really good too. Also, some Israeli sites have a lot of good stuff.
;-)
Security
Fact 1: we've never included exploits with our security bugfixes.
Fact 2: we've never committed fixes to CVS prior to announcing the security advisory. The fixes, releases, CVS commits and the advisories go out at the same time.
Fact 3: we've always cross-posted our advisories to secunia.com, bugtraq, etc.
Open discussions
I might have misunderstood Moshe here: http://drupal.org/node/31197#comment-44350 .
Secret fixing, announcing when fix is publicably available as upgrade makes sense to me. Hiding information about the vulnerability until a fix is available also makes sense.
I took it Moshe was concerned about divulging possible bugs which could be exploited. If he was, then taking proper care to keep it under wraps should be taken.
;-)
Security announcement mailing list
I'm setting up a security announcement mailing list. It should be available later this week.
Screenshots with comments
What does a module add to the administer menus? Before and after screenshots or a screenshot with circles around the new bits.
What does a module add to a page? Screenshot.
What does a module add to the database. phpMyAdmin screenshot.
http://petermoulding.com/technology/content_management_systems/drupal/
petermoulding.com/web_architect
Good suggestions ...
.. and the aching point about this all, is that if not drupal.org does this - someone else will see that there is a "market" for this - and just include some Google Adsense laden pages with the little effort done to provide these services to people.
That might not be such a bad thing (for Drupal newcomers), if drupal.org maintainers won't (or can't) do it for various reasons.
We did not have the hardware
We did not have the hardware to accomodate this until recently. The hardware is currently being installed, configured and made ready to transfer the mail list and cvs archive over now. (drupal.org and webserver done and announced already)
When this is done, there are several things we would like to do. User ratings and such, but quite frankly, it takes time and people. There have been various discussions onhte infrastructure list and such.
What's with all these comments about what 'us site- maintainers' 'wont do' lately? We are unpaid volunteers you keep kicking with your little extra descriptive comments, what did we ever do to you?
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
drupal.org
.. should be the place to include and collect the various pieces of information about Drupal and contributions to Drupal. Improvement is needed to drupal.org, but sometimes we see contributions or suggestions get turned down for various reasons. But when the submissions make sense, or improves the drupal.org experience - some effort should be taken to include the improvements - at least a positive answer akin to "to-do".
I think that Robert is right, that drupal.org should be the "drupalforge". There might not be any great harm if someone else does so, but it would be easier for newcomers if they could find the basic information they need on drupal.org - without having to battle accessability inadequacies to do so. Drupal already offers many out-of-the-box features to improve accessability on drupal.org.
I ask again...
I ask again.
Anyone can post a handbook page.
Anyone can answer questions.
You keep making these little comments about what we (site maintainers) won't do. If you think the documentation is a problem, then work on improving it. What documentation do you think is inadequete? I look forward to your submissions to the handbook with great expectation.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
It's a small step for ...
me - a giant leap somewhere else.
Here is one of the favourite contributions you'd like to forget: http://drupal.org/node/30976#comment-53833 . It seems easy to forget if it was your post it replied to and you counter-replied.
Perhaps, it's not you I should speak to about contributions ? Silly me ...
Sorry Dries...
Hi Dries,
There's no need to get so defensive..I love Drupal..but I just notice that drupal.org it's getting more and more diluted and I raised these discussion points because I care.
Please respect that.
If I could offer suggestions to your questions:
(a) I would urge everyone to NOT use the drupal-support irc channel.
It destroys the concept of having forums. Whether it's for development or for support.
I remember one evening I spent, I kid you not, over 3 hours helping someone install drupal. Over 3 hours. That's 3 hours of wasted typing in terms of developing a knowledge base.
(b) I would urge every developr to NOT use the #drupal IRC channel
It destroys the concept of having module development forums and building a knowledge base.
It helps turn Drupal.org into a place that veterans with answers avoid.
(c) Contributed modules are not really contributed modules. They are modules that have been contributed by people who have had the patience and gone through the process of learning how the CVS works.
There's a huge difference.
One of the best modules I came across recently was off-site. the only reason it wasn't in the Drupal/modules folder was because the guy didn't speak english well enough to know how to go through the module developers guide, apply for an account etcetera.
I got in touch with the guy..and even though I'm a novice, I offered assistance with being a conduit of sorts. Interestingly, I think it shouldn't be released as a new module, rather as a patch instead. (I'm talking about the flexiMAX.module patch).
My point being that a superb module/idea that would be useful to a lot of users wasn't contributed and wouldn't be where it's at today if it wasn't for an accidental click on my part (I discovered it totally by accident)
To answer your question about organising the modules..others (above) have linked to examples of user friendly and categorised module repositories and I know that revamping the modules and downloads layout/categorising is a W.I.P. That will help..but that's not really the key issue.
I think a simple approach could be followed where veteran drupaller blogs are enabled on drupal.org..so veterans can wax lyrical, share ideas and more importantly keep a grasp on what exists already, what's in development etc. without having to check what others are doing on the many many drupal offshoot sites that are spreading..scattering all over the web.
I suppose, I'm talking about harnessing what's already there..not changing things, as such.
Am very aware how any mention of changing the status quo raises defensive arms on here..it's not really necessary..
With reference to the "one-click away" comment, Dries, there are thousands of one-click away pages on drupal.org. Thousands.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Chiming in again
I just wanted to make a note that some really, really great forums use these techniques too. One example is a "traders journal" where veteran market traders will share their techniques and knowledge.
Here's a forum I've been using a few years - it's actually the world's biggest trader-forum : http://www.elitetrader.com/ - check the journals-section to see what I mean. There are mentors, students, followers and whatever you fancy there.
So, it's not something unfamiliar to me, and I know that the "veterans blog" works - and attracts a lot of readers. It's a proven concept and an out-of-the-box feature with Drupal. Too bad if there's no room for such a thing on drupal.org - but others might see how it works and make the idea real.
addendum..
sorry..just a quick addendum to my post.
I suppose one of the key difficulties for new users, module developers and everyone for that matter is that because all the modules are lumped into one page it's extremely difficult to work out if:
So while categorising modules will help aleviate that problem....i.e. when people are looking for a module, they should have the option to browse functionality driven categories rather than version driven filters.
That might sound silly..but, I was chatting to one of the developers of a (yet another) emailthispage.module and he didn't realise the module already existed. Only after he went away and created the module, did he realise there was already a version 4.5 or CVS (can't remember which) so all he had to do was upgrade & patch an existing module rather than unleashing yet another duplicate module on the community...which confuses everyone and is a waste of time.
Linking this back to my point about "contributed modules not being contributed modules" and more being modules contributed by people have have a CVS account...the emailthis page.module is a classic example of how flawed the contributers process is. i.e. if you get a CVS account it's not based on the merits of the module..rather the qualification for a CVS account....
I know that the handbook points to the fact that duplicate modules are not welcome...but, the way the CVS is presented makes it very daunting and unweildly to categorically check to see if a module already exists...
The dilution and scattering of drupal.org in general compounds that..who is to know that the module doesn't already exist in some shape or form on an off-shoot site?
I'm not suggesting changing the CVS status quo. I'm merely suggesting that the presentation and process might be tweaked a little.
I hope that makes sense..
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
+1 on developer blogs
I think that would be fabulous, whether it's everyone with a cvs account or just a few of the folks who've been movers and shakers here. I think it's a great way to encourage some public thinking out loud that's visible to others. (I for one learn a lot from the various developer discussions that happen to take place on the forums.)
As we say here in America, it's "the vision thing." Might be a nice addition to activate as an addition to what's here already.
Laura
===
pingVision • scattered sunshine
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
I think Drupal Planet is the
I think Drupal Planet is the better solution. I have seen and followed your posts from there.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Perhaps you're right
And I'm flattered that you've been reading some of my thoughts. But I wasn't suggesting blogs on Drupal.org for me but rather for those who are in the core development. I would hardly consider my sporadic support/docs/theming contributions worthy of an on-site blog. But if some core developers blogged about what's going on, what's being discussed, from personal perspectives but under the official collective brand, it might prove helpful and help forge a renewed sense of community.
But then I'm not 100% on this, either. It's a bit undemocratic, and perhaps a subset of developers blogging here would present a distorted or unrepresentative picture of the course of events and thinking here.
I love Planet Drupal -- it's one of my must-reads now -- and maybe its mere existence here will encourage more blogging about Drupal and eliminate whatever vague desire I might be feeling for in-house blogs.
Laura
===
pingVision • scattered sunshine
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
maybe a taxonomy?
Most people who are looking for modules click Downloads --> modules, and get the full list. Its too long, too unmanageable. In a sense that's great, but what if it was a better list, that made it easier to find modules that provide the functionality you would like.
I think a valuable first step here is to come up with some good categorization for the modules listed on drupal.org. A few well thought out taxonomy terms could be used to filter the huge list of modules, making things easier to find.
This deals with the issue of finding multiple modules that do the sames thing. It will also force some definition of what the module does.
Some ideas
What is missing is a way of corralling smartmobs insight here. How do people rate the modules on features and stability? Dedicated comment threads -- perhaps integrated into the project feature, though this can get to be a laundry list, rather than a discussion. Actual numerical ratings, like FF extensions get from users, could also be very useful.
Also, having an easy way to sort the module list by date of most recent commit to that version would be INCREDIBLY useful -- and make it much easier for admins to check on possible updates on modules they use in various sites.
Coming up with some sort of category sorting of the modules could be useful, too, perhaps using taxonomy to tag the module's page. E.g., posting, filters, email, rss, media, taxonomy.... (with multiple selects possible, as many modules would fall into several categories).
As for missed posts, +1 to the idea of adding a tab or link to read unanswered posts. I can check in only every few days, on average (sometimes several times a day, sometimes a couple of weeks in between), and aside from visually scanning for '0' responses and paging through, there's no easy way to find them.
Re outside modules:
It would be nice if we could somehow attempt to track and link to the various modules that are out there on other sites. Even if it's an informal effort as a new forum (or perhaps using 'weblink' module?), it would help us all not only find what else is out there, but also perhaps lead to new ideas for modules new or existing in the cvs path.
The simplenews newsletter for security issues is a fabulous idea.
Thanks.
Laura
===
pingVision • scattered sunshine
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
improve module display
The downloads section has been greatly improved over the last year. However, I would love to see a couple simple improvements.
I do feel that the modules have gotten a little unweidly as Drupal has gotten more popular. But only in their display. So far, once I actually find out about them and get them installed on my site they work faboo. Hope this helps.
bryan kennnedy
Some code is used outside Drupal.
There are a number of reasons code is outside the Drupal CVS. I found a three reasons to keep code out.
Some of my code is used outside Drupal so instead of Drupalising the code, I developed an interface for Drupal. The code will not be Drupalated because Drupal is not yet OO. Instead I made one class interface to Drupal and the other classes talk through the interface.
One of my modules, vocabulary_node, is Drupalesque because it looked like it would fit the Drupaltecture, I was writing the Drupalette from scratch, and I was going to contribute it as an optional add on for the existing taxonomy/taxonomy_menu group. I then found out someone else is rewriting the existing taxonomy module to do what my code does.
I like to experiment first. Some of my experiments are not yet complete. I do not want to put something in front of people if I have no immediate plans to finish the code because people might start using it in the expectation that it will become complete. Perhaps the Drupal module list could indicate modules where people are part way through development of a new module and want a little help or testers. I would help an existing project if the objective of the project fits my need and the project has reached a stage where it could be ready when I need it.
http://petermoulding.com/technology/content_management_systems/drupal/
petermoulding.com/web_architect
Dub, kudos for raising this
Dub, kudos for raising this issue
69 replies and still growing. Well, it is the feeling for any new drupal user or a user who have spent more than a year like you otherwise this post wont be bombarded with so many comments (active participation) in a day.
Boris said,
If developers can't learn it, they can't participate in open source development....EXCEPT on Drupal.org, where we have a patch process in addition to CVS.
Would like to know the duration for a module maintainer to commit a patch ? The earlier the patch is committed the faster the bugs are fixed.
I feel contributed modules should be ordered by the last patch committed date and with a counter that shows number of downloads so far, it is one of the way of determining if the module is active and also its popularity aka participation
Currently, it is just ordered alphabetically
http://drupal.org/project/Modules and
it is hard for anyone to know if the module is active. unless users dig in to cvs etc.,
To reduce the confusion of similar modules i thought it would be better to have a broader category and modules can be assigned accordingly. For eg, for category image
we can have Name of the module like (image, image_assist ...
i mean image associated modules), Author name, Description of the module, Similarity, last commit date, module created date.
Likewise for multimedia category we can have audio, video etc.,
It also reduces the uncertainty as you will know if the module is actively supported or not. Similarity column will let us know if the module has derived any of the features of the other modules in the same category.
Currently, it looks scattered.
2 cents.....
Hi,
Just my 2 cents worth as someone who just very recently came to Drupal (you can thank a Computerworld article for that).
Coming directly from trying Mambo, I'd say the support forums here as far as the ratio of answered questions to not answered is about average, you're always going to have the impatient ones who give up if they don't have an immediate response. This said, the first 4 or 5 questions I posted didn't even get a RTFM response, which it turns out was fine because it just forced me to figure things out myself which has already benefitted the community because I chose to write a few things up and submit them (I think people hesitate to do this because they're afraid they'll mess something up or end up being wrong)
However, I must say that I find the way the forums are presented a bit.....cumbersome to deal with. I'm talking about basic navigation, searching, that sort of thing. I'm not sure I can put my finger on what exactly is throwing me off, but something is. I'm just an oddball, I guess.
The biggest problem for me has been searching. I'm pretty good at searching out things, but finding stuff on the drupal.org site itself has been a challenge. I'm finding that the information is there a lot of times, but doing a search doesn't necessarily bring it up, I usually find it by going page by page through the handbook until I hit upon something that looks likely then branching out from there. The search results of a site search using the built in search leaves a lot to be desired, IMO. My best results have been, as usual, from using google and I'll second your comments on some of the how-to articles elsewhere, there are some really good ones.
I like Drupal, though I'll admit that I almost dropped it and went back to Mambo, but I since I don't really have anything pressing that I want to do by way of a web site I figured I'd play around with it some more, wait until the next version comes out and see what's different.
Drupal's good stuff, but there's just a.....level of difficulty.....in finding the answers one needs to make it work well that tends to be a turn off to a newbie. No one single thing that I can point to, just an assortment of little piddly things.
Just a few observations, no solutions to propose at the moment I'm afraid.
Joe
you're not an oddball Joe..
thanks for chipping in.. as a mambo veteran your comments are appreciated. It's tragic what happened with that.
I don't think you're an oddball....in my opening post I mentioned that drupal sites need a lot of troubleshooting...part of that troubleshooting problem for a non-programmer like me is:
Time spent troubleshooting:
Of course a PHP programmer would probably intuitively know what the problem is or what caused it in half the time it takes me..or worse..they would simply know where to look.
that, for me, is an un necessary stumbling block with Drupal and while the forums on here look great and distinctive, it lacks fundamental functionality that, in my opinion, is essential.
Such as:
A method of searching posts by version or date
When you search for a problem, Drupal.org indexes every single post in the database. That is not necessary. Why not run a search for posts tagged with the current version...or simply posts that date back to the release of the latest version by default?
If the search doesn't pop up any answers..fine..a dropdown box could let folk search back further...
provide an option for sorting search results by date
How many times have you searched for something and a post from 2002 comes out first?
tagging/rating posts
Getting closure on a thread on Drupal.org is generally quite good although I think it might be improved is users were able to rate posts.
As an example, the current method is searching by words. That might be improved if there was a CLOSURE option on a thread/post that would tag the post as a good solution for THIS.MODULE from THIS.VERSION of Drupal.
My point being that people are not really searching for words. They are searching for solutions.
If people are searching for ideas, they will (now) go to drupal planet.
email me when there's a response to this post
A fundamental and essential function for any decent forum.
convert to handbook page option
Often I have seen a superb post that would, with a little tweaking, make a great handbook page. Invariably, when you see something like that, it's because you are looking for something else and probably under pressure to get something finished..or a looming deadline.
Why not have an option that "pushes" or "shoves" a post into a "convert to handbook" page queue...which is viewable by the site maintainers.
the way it could work is as follows:
The same could be applied to posts that are rated very high.
I think this will work. A while back I started a php snippets thread on drupal that turned into a huge thread and difficult to follow..I decided to create a handbook page that would keep all those snippets together...since that, the snippets page has grown and grown...usually by users who simply spot one or post one in reply to a question and then paste it into the handbook.
So, I don't think you're an oddball Joe. The Drupal forums, look great, but the functionality is lacking. Which is a pity and a frustration for veteran and newbies alike.
Ironically, it's much easier and much quicker for a newbie to post a question than it is to search. Without stating the blinking obvious too much...it should be the other way around.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
search drupal : suggestion to use google too
i suggest you use the "site:drupal.org here_your_keyword and_another_keyword" feature of google (and other search sites)
i find the combination of drupal.org search, google, yahoo and sometimes msn the best way to find what i need
...bigger problem is to find the right keywords
-micha
work in progress with Drupal 4.6: langmi.de
people are searching for solutions. not words
I disagree micha.
It's a good workaround that I often use myself because of the drupal search...but, in google you are screwed if the post is indexed in google under a taxonomy term, i.e. the keyword you searched for will pop up links to /taxonomy/1 or similar type pages...which is pointless.
the bottom line is that people are searching drupal.org for solutions. Not words.
So it would make more sense to introduce a post-tagging system, not unlike the tags that are applied to issues/patches etc. so it makes it easier to find the solution you are looking for.
At the moment if you type in a string to search for..every post on the site ever is indexed that has that string. if you're lucky and other posters were dilligent when wording their post, you might find your solution.
More often than not, you are left with pages full of post links that have very little to do with the version you are using and some posts as far back as 2002 or earlier.
I think that's unnecessary.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
only a suggestion
after all its a suggestion :-)
and im not sure, why drupal should work hard to copy some search functions (index etc.) when google and co. have it already
its a hard task to get an "intelligent" search function, id rather go for good meta-data per page to get better results
keywords or even weighted threads is hard to archieve (at least when we talk about automate processes), again im not sure if drupal should make it on its own
my suggestion for support forums only
--> maybe drupal.org/forum should go for moderators, they can mark "good" Solutions, give keywords and such
-micha
work in progress with Drupal 4.6: langmi.de
As far as the search goes,
As far as the search goes, I'm holding off on really making any formal feature requests for it until we've got a release that includes Steven's recent work. That patch addresses what I think is the single biggest problem with the current search: the lack of an 'AND' search. I'm betting that the signal to noise ratio will improve quite a bit with that alone.
That said, sorting results by date is first on my wishlist for 4.8...
you've just touched on something there Toe..
Stevens recentwork looks good..but, I sometimes cringe when I see posts or messages about great ideas that are pencilled in for version 4.something or 5.something.
the development cycle is staggering with Drupal....but I think it's slightly too quick and my guess is that because the core developers are more than likely using a CVS version of Drupal...they don't get to really use the current version and experience the gremlins and glitches that only reveal themselves when you actually use it daily.
i.e. the developers are already ploughing ahead with the next version. Assuming that all that they've left behind is working. I'm not criticising the staggering speed of development, I'm just saying, slow down a little and improve what we've got.
I get the impression that it's a chore too far for developers to jump back in to Drupal 4.6.0 to fix or tidy up stuff. It seems to be much more fun to plough ahead with new and exciting projects for version 4.8 or 4.9 or 5.0. Whatever
That's a generalisation, I know and in the same breath, it's worth pointing out that there is a code freeze on and a lot of issues do get sorted.
the point being that the general scattering and dilution of the drupal.org community is creating great releases and great innovations...but, it's a bit of a struggle sometimes to keep up with what's going on..
Why is there huge discussions about drupal 4.8 modules when there are fundamental improvements that could be made to existing modules?
It's difficult to write this without sounding like a critic..but, I suppose what I'm talking about is the fuzzy lines between stable and development versions. where the stable versions aren't improved upon because the developers are more interested in developing the next generation of ideas, concepts and features. I can understand that..it's more fun than dealing with quality control issues.
The scattering and general dilution of the community compounds that problem and creates a domino effect of dificulties back through the food chain to non-programmers (like me) who struggle to keep up with what's going on, use the update scripts and tweaking the new base Drupal scripts for production sites..
I hope that makes sense..and I often wonder how many users are afraid of upgrading and just leave their sites in all their tweaked, hacked and patched 4.something version?
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
I use both
Depending on the needs of my clients, I install either HEAD or the latest CivicSpace release. I like the stability and large number of supported modules for CivicSpace, but some things just can't be done easily on 4.6.x (multi-region block placement, for example). So at least for me and the 4-5 developers who work on projects with me, we use both.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
As a programmer ...
.. what attracted me was the ease of which I could augment Drupal functionality. The core Drupal is sufficently clean and not overwhelming in terms of lines of code, so it's easy to figure out how to fit in more when Drupal fundamentals are understood.
For some time Drupal has been seen as "programmer friendly" and "technical" with respect to deploying and molding to one's needs. It's inevitable with these growing pains as popularity grows. It seems there is work going on to make installing and updating (hopefully) much easier with the install system (forgot the name and link to it now).
I still think that "some" programming/dba skills are needed to get what you'd like out of a Drupal installation - but things are improving. One of the tougher situations are with inconsistencies in the database causing obscure problems for the typical "non-dba" webadmin. Some modules include the db schemas in their setup, while others require manual altering/creating of tables.
As this gets more attention by newcomers without the skills of dba/PHP, the more it's chances of getting fixed also rises. Someone will "fix it" by adding small fixes for their specific situation, or whole install systems as the one being worked on by core developers (I don't know too much about it).
Some draw the parallel to Debian and the work being done there - but they have large resources in release QA, documentation and testing. Drupal isn't there quite yet - but growing fast.
;-)
The growth of options,
The Drupal.org homepage , RSS feeds and tracker do not have enough real estate to give recognition to specific topics, problems and solutions.
For this single reason, the growth of options, websites, ideas and information is inevitable and unavoidable...
We just need useful, newbie-friendly ways to find it, classify it and rank relevancy.
5 years from now the Drupal National atmosphere will reflect the efforts taken to make it's information useful, newbie-friendly, easy to find , classifiable and relevant.
Good discussion...
Marcel
http://drupalhacks.com - coming soon
http://drupalthemes.com - coming soon
I agree.....but..you have two drupal[variation].com sites
Hi Marcel,
thanks for chipping in.
A tad ironic..but, I notice that you are planning to unleash two new drupal sites...drupalhacks.com and drupalthemes.com
Would you be averse to setting up a drupal-hacks blog and a drupal-themes blog at drupal.org?
Or is it important for you to do your own thing, seperate from drupal.org?
Perhaps I'm not being very clear, but, the overriding point of this thread is that it's better to encourage people to maintain their blogs at drupal.org..rather than at their own seperate, scattered sites. Users could include in their signature a link across to whatever site they want (within reason).
Does that make sense?
The scattering of the community is inevitable as Drupal grows..but, without a central, cohesive community hub (i.e. drupal.org) the community gets diluted, drupal suffers, people get miffed and we get situations where we have numerous people creating their own modules that are doing the same thing.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Not putting down your comment but I was told to do it
In my case where I wanted to find out more about the drupal.module and distributed authentication
I was told to create a distributed authentication module or at least this is the idea was left with.
To use the project tracker to look for an alternative but the search button is still hidden and it makes for a long tedious day trying to make it visible with every search.
I don't understand why I should have to do this when there is a perfectly working drupal module. The is already for use with each install. I just need to understand how to make it work for my stuff.
I am going to wait for the WDDX module and work it a bit to see if it does what I need. If it does not then I will have to peice together a clone of the drupal module that works and is understandable. Since this is for a county service and being run by students the clone will probably not make it back to Drupal.org but float around on each students account elsewhere.
Distributed authentication
...is not all that secure as it's implemented now in the drupal module. It's not "perfectly working" at present. FYI....
Laura
===
pingVision • scattered sunshine
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
There are a couple of
There are a couple of modules in contrib that may suit your purposes better.
SXIP and the LDAP authentication one.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Thanks for the suggestions.
Thanks for the suggestions. I have already tried to get them to use something and LDAP is what they are going with but they will be using an IBM product that was donated when they extended the Lotus Domino licenses.
So it looks like I will get a break from my pain because now all 5 locations and any new ones are going to be on Lotus. Now I can go back to lurking :)
avoiding assumptions
I don't have time to blog, but I help in the forums.
What is important to me, isn't necessarily important to someone else. Everyone one of us have different reasons we use Drupal.
It's Utopian to expect everyone to learn and research exactly the same way. We can't assume that everyone has the same needs and motives.
We also can't assume everyone knows how to make patches, code modules, work diff and cvs. I don't... and I don't have time to learn *YET*..
Besides, I don't know of any open source or for profit businesses that suffered because of "fan" sites.
see http://phpbbhacks.com
see http://www.vbhacks-germany.com
see http://www.vbulletin-tutorials.com
see http://www.theadminzone.com
see http://www.vbulletin.org
This is not mine but see http://drupalforum.com. One day it will launch. I can't wait to see it get started...
Also not everyone speaks english... German, Chinese, Spanish, Portuguese exist too. Where are those foreign language forums... We can't expect Dries to think of everything, police everything. Someone somewhere has to step up.
We need the Michelin's of Drupal. We need the independents...
Hope that makes sense... (But It does not have to....)
Marcel
http://drupalhacks.com
http://drupalthemes.com
It certainly does make sense
There already are a lot of language- or region-specific about-drupal sites. A good start is the drupal.org site for anyone looking to find them.
;-)
thus proving that they fill
Exactly. They fill specific needs.
Not using Drupal...
Hum, do you know the guy behind it ?
There's no post and I don't feel like inaugurating the forum by posting a "Why don't you use Drupal forum"...
Dont know him... But let's
Dont know him... But let's hope he sees this thread.
I'm not sure I'm with you Marcel
I'm not so sure I agree with you Marcel...
It could be argued the reason drupalforum.org is starting is not as a "fan site, it's because the drupal.org forum is fundamentally flawed and unable to cope with a real community. It looks great. But is not very efficient.
If I do a search for anything, the search engine checks every single post since the site started. That is crazy, unnecessary and a waste of processing time.
It should default to the most recent date of a significant version release...and then offer options with the results to dig deeper.
I work in music and fan sites are a great geurilla marketeers tool. the genuine fan sites evolve out of genuine love of a bands music.
The general scattering of drupal development and offshoot sites is because people are left with no other option or are simply "pushed away" by drupal.org.
You are correct, drupal.org and the drupal project needs independents. But it needs the independents to engage and congregate at a central community hub. Whether that's at the hungarian drupal site for hungarians..or a french drupal site for french people.
But at the end of the day, the de facto central hub for drupal MUST be drupal.org. That to me is essential.
The fundamental incentive behind the ermergence of yet more offshoot sites like the drupalforum.org you mentioned is indiciative of a fundamental flaw with drupal.org and the drupal project.
I'm not saying "the end is nigh" and we should be dropping sandbags on the virtual levvies..I've just observed the increase in this scattering and general dilution of the community that is having a detrimental domino effect on the whole project.
We should not be jumping up and down with glee at the notion of drupalforum.org...we should be ashamed and embarrased that someone felt the existing drupal.org knoweldge base so inefficient they felt no other option but to setup their own offshoot....and to add insult to injury, they have used a non drupal piece of kit to build it.
How mortifying and how embarrasing is that?
the bottom line is that off-shoot drupal sites are generally emerging for all the wrong reasons...they're not fan sites..they're sites that were borne out of frustration..not out of adoration.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
I want results... So do my
I want results... So do my bosses. I have projects to complete, and deadlines to beat... If today, VB can get the job done I'll would use it too.
I love Drupal, I really wish it could beat VB at it's own game. May be in 2006, 2007 or 2008... but not 2005
It can be done... Nothing is impossible. But let's keep Drupal focused, organized, civilized, nimble, not bloated and easy to install.
Yahoo used Google for a number of years, Google uses Dmoz.
Options are our friends... not enemies.
Marcel
http://drupalhacks.com
http://drupalthemes.com
http://drupaltalk.com
thats a very good point..
Fair point. And well made.
I think there is an opportunity with the launch of drupal 4.7 in a few months...to launch a new forum with that. I think it would be worth it..whether it's a redeveloped drupal forum (I have read some great ideas on here) or a phpbb integration or other..it doesn't really matter.
Totally agree with what you just said. It makes perfect sense. The only thing that's good about the drupal.org forum is that it looks different. BUt once you start using it, you quickly realise how inefficient it is as a forum/knowledge base.
Perhaps between now and the launch of drupal 4.7 a mini-forum-specific develpment team could be assembled to look into this properly..and I don't mean a forum post on here "let's have your ideas lads"...I mean a concentrated, collaborative effort that's goals are simply:
As a milestone, the launch of a new version is perfect. As it's starting with a carte blanche, so to speak. A new dawn, a new age and all we have to be careful with is not to throw out the baby with the bathwater.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
My approach
.. was to first start with the threading and the URL as this was the central point to making an alternative not too intrusive on existing Drupal functionality (I just disable comments in my systems).
I.e check out the nodeapi 'insert' event, and you can hook any additional stuff to that. Here's how it works:
www.mysite.com/node/add/post/respond/pid
That means it's a normal node.module add content of posttype - it could be story, flexinode or whatever (just configure the links, permissions etc). It also adds the information about the parent-node-id or pid like I labeled it. It would be a numeric argument of course.
E.g so you would just supply the following link to your node/32360 -
<a href="/node/add/post/respond/32360"> respond </a>.The node insertion would be handled normally by the node.module doing all the menu callback motions, and you would only piggyback that with the nodeapi 'insert' event being invoked by node_save() - where you check the arg(3) and arg(4) for 'respond' and is_numeric() respectively - as well as the preceding ones. Then you would know the parent-node-id as arg(4) and the response newly inserted node-id as $node->nid in the nodeapi hook in your module.
That is all you need for threading proper nodes. Now, was that a Drupalish clever and clean way to do it or not ? Hope you could follow me on this one, I know you did some great stuff on fleximax, but don't know how well you know Drupal innards. I don't use the 'respond' word however, and have various node-types for posting various stuff (it's more dynamic according to security permissions and context).
You should also check out the node_submit stuff to get a drupal_goto back to your thread-context of your post, and not the default lone post-display for creating node'ish content.
This is the beginning key to making a non-obtrusive alternative Drupalish module for a forum anyways. Then comes all the stuff about presenting, collating, caching, optimizing etc.
;-)
PS! You probably should start a new thread for that, or use the one by Toe (was it?).
Drupal = many projects not 1
I agree w/ Dub, Toe, der, et al. Drupal.org could achieve more.
New to Drupal & PHP x 5 months, I recently developed my own module to do node-to-node associations. Still enthusiastic about contributing to Drupal but fear I will not be granted CVS access (applied ~a month ago).
I also found (after many hours) a group working on related project, but there seemed to be no coordinated effort that I could contribute to, nor interest in my involvement.
I embrace the need to keep out riff-raff & agree that I have the credentials of riff-raff. But I really would like to get my module out there to allow for others to discover it. Agree w/ Dub's vision of a capability to submit rough work for the world to see/discover.
Broadly, I think Drupal.org could use more clearly defined projects w/ project areas, owners, developer lists & recruitment rather than current impersonal & boundaryless feel that drupal.org has. Dries made the point that there are > 300 developers w/ CVS access. But perhaps we should compare drupal.org to sourceforge.net, which has thousands of CVS contributors divided into thousands of cohesive teams. I think of Drupal as not one project but many.
Drupal.org could also use more explicit tagging of general postings by project/module that the post refers to. That would help the search problems others have highlighted.
Also agree IRC + email lists diffuse the focus.
Don't get me wrong- I love drupal, drupal.org, and all you beautiful people. I just want to be able to help.
dado
The mailing lists are archived/searchable....
The mailing list archives can be found here:
http://drupal.org/mailing-lists
True it involves a lot of work, cause you have to search then individually.
I've never been on the Drupal IRC, so I don't know anything about the noise to intelligent chat ratio.
If the chats are that good, maybe we should save them and make it searchable. or maybe not...
Marcel
http://drupalhacks.com - offering the wddx hack this week
http://drupalthemes.com - opening soon
thanks dado...
Thanks for the well considered and well thought out post. Appreciate it. Am enthused by the positivity.
I think it's a given that we all love drupal...the main thrust of this thread is to improve drupal..
+1 for dumping the IRC channels.
They destroy the value of the forums and dilutes the notion of a knowledge base.
-1 for dumping the email lists
I sometimes find them handy at work when I don't have a chance to log into drupal.org. besides they are just the "headlines" from recent posts, are they not? and you can unsubscribe
+1 for rethinking how the forum's work, especially the post tagging idea.
+1 for a smarter presentation/general architecture, especially classification-by-function, not version, driven contributions section.
+1 for an "in the wild" contributions and snippets section, where often superb, useful, orphan and wacky modules live before being adopted by one of the 300+ drupal developers who have the necessary permissions.
+1 for switching on veteran blogs on Drupal.org with the option of (max) 20k attachments.
+1 for encouraging people to "report back home" on drupal.org instead of enticing people away from drupal.org with their own little drupal[insertvariation].org site.
Planet drupal is a step in the right direction, but it is just a lump of content and isn't very well thought through. Why aren't the feeds simply categorised?
+1,000,000 for passing round a peace pipe so we can actually have an objective discussion on here without descending into a "if you don't like it, please shut the door on your way out" discussions.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Yes, no reason to give up
Change is hard for many, and admitting they are wrong is even harder. So, all shouting aside, some good will probably come of all of this - so thanks everyone for participating.
;-)
Just an idea...
In addition, I suggest a "Universal Info module" that can
- search drupal related websites
- search drupal mailing lists
- receive tags
- receive comments
- insert your cool communication idea here...
It should combine all del.icio.us features + comments.
It would combine features of the Bookmark, search modules + aggregator + modications....
I sure this was thought of, but it's worth highlighting
Time to disagree! :)
I'm the other way around, I favor dropping the mailing list discussions (excepting the one-way notices I mentioned before), but keeping the IRC channels.
To me, that advantage you listed for keeping the mail lists is so small as to be negligible. I mean, if you honestly can't pull up drupal.org at work, you can always do it later at home. The advantages are completely outweighed by the disadvantages, IMHO.
IRC, on the other hand, provides a benefit that neither forums nor mailing lists can do: realtime exchange of ideas. Ideas flow differently in a realtime media like IRC than they do in a time-delayed media like a forum. There's also something to be said for the instant gratification aspect of it.
IRC also allows for a 'meeting' enviroment. Drupal core devs could have weekly/monthly/whatever meetings in IRC, and then post the log of it to drupal.org. Same goes for anything else people colaborate on.
I would actually favor making IRC more accessible. There's tons of people out there who have no idea what IRC is. Finding a client (which isn't provided by drupal.org) and figguring out how to set it up and connect to the right channel is a good bit of work for the uninitiated. There's quite a few Java IRC applets out there that let a user join the channel right from their browser without needing to install anything. I use PJIRC on my website. Right now it's just a hard-coded page. If there's enough interest, I might look into making an actual module out of it.
IRC and hosting
Most webhosts don't allow IRC-related connections or scripts, but for someone hosting from home or with better control over the server and network it would be very interesting.
quick question..
Hi Eldarin
I'm intrigued by some of your ideas for forums....can you drop me an email? (your contact form in your acccount isn't switched on).
very interesting.
cheers
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
I have no contact form enabled
It makes open discussions easier, and separates work projects clearly.
I probably should collate the stuff - but I think most of it is stated in Drupal project issues (not easily searchable, I know), some are hints in forum topics.
Basically, it means using full-fledged nodes as responses - i.e creating node content (of any configurable, extendable type) and using a threading-table to keep track of them. Then presenting threads, forums, posts all becomes issues of how to do the caching, themeing etc. I try and pre-calculate as much as possible when creating new posts - then it displays faster. It means replicating a lot of parts (already themed etc) and keeping very good cache-control.
It is *not* a trivial Drupal affair of coding, and means a lot of work when complicating with flexible security.
Hey, if you guys are going
Hey, if you guys are going to be discussing possible improvements to Drupal's forum system, why not take it to The Big List? ^_^
what a pity there isnt a drupal.org blog for this..
Thanks for the heads up toe...nice one.
I think that's a classic example where for a drupal.org blog would be served better as opposed to a forum post.
It's late here..but I will contribute to that when I get a chance.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
A java applet is different
A java applet is different though. I'm quite familiar with general web host attitudes toward IRC, but I've never heard of a host barring Java applets. In the case of a Java IRC client, all that a host is involved in is serving the jar files themselves - it's just like any other file they host. At no point does the actual IRC connection pass through the host's network - the connection is made directly from the enduser's computer to the IRC server.
Maybe
.. and you might convince them otherwise, but some have TOS clauses simply saying "no IRC-related scripts or services". Then it would be up to each and everyone to ask specific permission to make things clear.
I understands how the applet would ask permission capabilites to connect to other hosts (IRC servers) and thus would not actually run any IRC network traffic through the webhost or their networks (yes, some network providers ban IRC traffic too).
It would still be a nice addition, and lets hope the webhosters stay reasonable or have more specific IRC-terms in their TOS.
;-)
Perhaps more to the point,
Perhaps more to the point, it's highly unlikely that the host would ever even know that it's there. Unless you're sucking up excessive CPU or bandwidth, or if they get a complaint about you, hosts very rarely take a look at what's on their own servers. Again, it's just like any other files they host up, and it's unlikely to cause one of the scenarios above where they check you out.
But in any case, I was originally talking about having it here on drupal.org. and I doubt it would be a problem here...
you have a point...but..
I think the IRC #drupal-support channel should definitely be dropped and people should post ALL support Q&A on a new improved Drupal forum.
I see your point about the fluidity and instant gratificiation of the IRC...but, the problem is it's scattering core knowledge that is essential for improving drupal.org.
If the drupal forum was improved and made more efficient, which it patently is not at the moment, it would do exactly what it says on the tin.
All those gems of information you're talking about disappears in an IRC ether once you close the window or log off. Whereas if the gems of information were posted on a good, solid and efficient drupal forum and it was structured in a simple way - there would be no need for the #drupal-support channel. Apart, perhaps if there's drupal.org outage.
So while I understand completely with what you're saying...I think, long term, for the Drupal project, the less scattering and dilution of the community like that, the better.
Similarly, the #drupal developers channel is diluting the community...I have only discovered gems like planet-drupal, the new control panel admin module and others since I started this post.
So the visibility of what's actually going on is diluted by the #drupal irc channel.
Again..I would argue that if the drupal forums were more efficient and structured in a better way, it would stop encouraging people to discuss, debate, argue and share ideas away from Drupal.org.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Log the IRC channel and edit it down...
You aren't going to get the IRC channel dropped. It's a waste of time to try.
You can LOG the irc channel, post it unedited (and searchable), or better yet, edited for content (and searchable).
that's useful to know Seth..
That's useful to know Seth...
And a pity. the logistical simplicity of having an efficient centralised community hub forum, I think, is vital as Drupal grows and develops.
Instead of spending time contributing in future on drupal.org...maybe it's just better for people to simply post "go to the drupal-support IRC channel" responses to questions, book pages and tips.
Maybe you could contribute a book page for the handbook that explains to people how to do what you just said with IRC channels. Or will the IRC #drupal community mind newbies coming in en-mass asking "how do I use this thing"..and you can explain as the question is asked?
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
IRC
.. is a communication medium which is even less formalist than writing emails, forum posts. Some prefer it when they want to mix more social or a flurry of topics, or maybe for other reasons. It might seem "quicker" to some.
For newcomers to Internet, a full-fledged IRC client like mIRC or similar is not good advice, but some of the stripped down java-clients are a safer alternative. That is especially because of all the security concerns with full IRC clients. They employ a lot of peer-to-peer protocols and functions, along with many (considered) unsafe practices (especially with all the fancy scripts).
Logging IRC channels is a fairly easy affair, but many times IRC networks experience "server-splits", and can get under constant attacks by what is called "script-kiddies", who use DoS attacks and similar. That could complicate some excerpts, making it difficult to maintain a "complete" log.
If one employs a dedicated IRC server, splits could be avoided, but the ircd server could be seen as more vulnerable itself.
Avoiding IRC itself, or other types of virtual meetings, doesn't seem possible. At least it's a more open forum than private meetings on other chat clients like Yahoo/MSN messenger, Skype, Netmeeting etc. That is if not private chat-rooms with passwords etc gets prolific.
A good way to catch some of these gems hidden within the IRC discussions (seeing as they are not likely abandoned), would be to log the channel(s), and also use some anchor tags within the logs and have them on drupal.org. These anchor tags could then be used as external reference for anyone wanting to link e.g a forum answer to a solution within some IRC logs.
Granted, reading a long IRC log with intertwined topics can be confusing at times, but at least it could be a contribution if properly anchored by some automatic log-script/-bot. There are some channel-bots available that would do this, if I am not mistaken.
There are even FAQ-type bots, which could "interactively" help answering you. I'm not sure if they uphold the same "interactive standard" as the Emacs elisp psychoanalyze-pinhead, or the famous "Elisa" program - but they at least resemble some telephone IVR menu system.
Getting some automated transcripts on drupal.org with anchor references could be an ok compromise.
;-)
/me raises hand to Dub :)
But the Drupal planet was announced in the forums.
http://drupal.org/node/31026
It was even promoted to the front page for a week. There was virtually no discussion in the IRC channel of it.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
lol....you love that IRC...don't you..
Hi Sepeck..(thanks for the email)..
I understand that I'm flogging a dead horse...or the words trying to move the mountain to mohammed, springs to mind.
As a compromise or meet-in-the-middle peace process offering...(or piece process, maybe?)..whatabout the following:
(a) #drupal irc channel remains for developers and IRC lovers.
(b) #drupal-support channel is scrapped or only used when drupal.org has outage.
Here's my reasoning:
how does that sound?
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
I'm ambivelent to IRC. I
I'm ambivelent to IRC.
I merely wanted to point out that your example was perhaps an example that even when folks post to the forums, people miss stuff in the forums all the time as well on the front page when you only go to /tracker.
IRC has it's pluses and minuses. It's merely one more method of communication. Your concerns are identical to the concerns of some when the gentleman who started #drupal-support set it up and then wandered off.
Good luck with your campaign and experiment though. We shall see how it goes. If you really wanted to hit it hard, you need to send a message to Dries asking him to remove it's mention from the support page. Of course, now that you have publisized it's existence more widely, I see that some are rushing towards it to use. :)
I myself have two goals in the next few weeks.... remember to ask Webchick to include her write up in the handbook on how to enact change as it is covers all the stuff I never have time to write and consolidate and post to the handbook all the stuff we gained from my config challange. After that, next challange.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Dub, your a great
Dub, your a great campaigner... Don't let IRC distract you.
There are so many other Drupal issues, modules you could help us hammer away away at.
One that note here are a few irc related threads:
http://drupal.org/node/32405
http://drupal.org/node/9999
Marcel
Unofficial Drupal IRC is
Unofficial Drupal IRC is launched see: http://drupal.org/node/32621
Support forum
There are lots of comments on forums. I just clicked on the Support forum link under support on a module page. Instead of getting a support forum for the module, I get the whole of Drupal. I think there should be a forum for each module even if it is a virtual forum created with smoke and taxonomy. When I click on the support forum link for a module, I should see forum entries for that module.
http://petermoulding.com/technology/content_management_systems/drupal/
petermoulding.com/web_architect
Forum to module mapping
Forum to module mapping would be great. The Project issues have partially taken up that role. But that's not first place the public and newbies would expect to look.
I am sure there is a reason Drupal.org does not offer One forum to One module .
- Maybe we do not have the server resources...
- Maybe the Moderator capabilties need to be strengthened
I don't know. Drupal is almost there, but not quite there yet...
Ironically the VB forum on DrupalForum.com would be great for that - when it launches
VB has the admin and Moderator capabilties for that.
Yes, I've been wondering
Yes, I've been wondering this myself. Since each project is a node, it should automatically have the capability to have comments attached to it. In other words, shouldn't there be a way to patch project.module to have "add comment" attached to the project node? And no, I don't mean submitting something to the issue queue. I mean just on the project description page. I think that way it would create a little mini-discussion board for each module.
great idea..
I like that idea zirafa. it is a bit annoying when you're on a project page and you click on support forums, only to be brought to drupal.org..as opposed to what you expect..which is a categorised forum for that module.
Your idea would also help the problem of searching for "something.module" and you get returned every post where "something.module" mentioned...as opposed to posts directly related to something.module....if that makes sense...
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Structural problem
You obviously hit a nerve here. 174 comments so far.
I think that the problems you decscribe are structural, to do with the tool. Change the tool and the problems will go away.
Spread of modules: Yep modules are spread all over the place. There are several problems and they are are all structural
Wwhen there's a small list of anything, a flat list is fine. But when the list grows large, other mechanisms are needed. The list of modules is too large for a flat list. What's needed are ways to dice and slice:
- which are the most popular
- what level of polish does the module have
- what groups of modules are there
- how to achieve particular effects - i.e. which modules to use
(Someone suggested a one set of very good categorisations: experimental, personal, and supported. I'd say that this is a very good case for a folksonomy so that people can experiment.)
When you go through the list of modules, find one that you think might be good, click on it to find details, you'll find that usually there's no way to tell that's it's what you want. This is another structural problem - the details that are held are not useful. What's needed is a full decscription, some comment by users, screenshots and a working example where it's clear what the actual effect of the module is.
Jeff
not with my hammer
The tool we're using... hmmm. I tend to agree... ok, Jeff said structure... (probably more semantically correct). This idea seems to go along with the forum issue above... (not being able to link from module to specific forum topic/area). It also seems to go along with the functionality that previous (non-compatible with the current drupal version) modules are not easy to find.
and Jeff makes some good points from a user standpoint... finding modules useful to fit a particular task. the current form doesnt work, besides providing a repository of module source-code links.
seems to me that you can't fix every problem with a hammer... even though my three year old would tend to disagree. :)
Michael Stewart
www.MediaDoneRight.com
it's great going with Drupal
I'm new to Drupal, but when I used installed Drupal for the first time, I was surprised, HHHUUURRREEEYYY, its already packed with most of the modules to start your own community forum, cms, searching feature, user management, content management, polls, blogging, content syndication, news aggregator, logging, reporting, caching, etc. The best thing what I like most is friendly urls, using this feature you can create a well promoted user and search engine friendly forums. What else you need, DRUPAL is great.
Jaspal Singh
Aadhunik Software Development Ecommerce Services Web Site Design Hosting Solutions Seo Articles Templates Scripts Asp Php Mysql India
aadhunik.com
Drupal itself should support cohesion
I agree that this is a concern.
I have made a couple of modules, which I've put on my own site rather than the Drupal one. This is partly because I found the Drupal process too much of a hassle (I applied for CVS access, not sure if I ever got it), partly because it all seemed too formal, and partly because I didn't feel able to commit to any sort of support - I was making modules primarily for my own use.
I am an experienced programmer, but I still find CVS to be a pain in the backside, compared to something like Perforce, or even Subversion.
Personally I think that Drupal should be a lot more dynamic itself in the way that it deals with installation, updates, modules, etc.
There ought to be a far cleaner "one-click" solution for a basic Drupal installation. Once you've got an installation, it ought to be possible to upgrade from within the administration page - you shouldn't have to download anything or manually run SQL scripts.
The same is true for installing custom modules and themes - information about them should be published in a way that Drupal sites can pick up automatically, so that all the administrator has to do is click a tick box to have a custom module downloaded and installed without further intervention. All of this would make an administrators job much easier.
We could then think about supporting the submission of patches, new modules, etc, again via a Drupal based interface instead of using CVS (obviously you can still use CVS under the hood).
The fact is that a lot of people who are using Drupal, and even developing modules for it, don't do it as their main job, and don't have a lot of time to devote to the process. Anything that supports them and makes life easier for them has got to be a good idea.
easy install
There's work going on for an easy install system such as you describe. I'm sure that they would appreciate help.
striking a balance..
Thanks for chipping in your two cents Sam..much appreciated..
I think the key is striking a balance between what the core drupal developers are used to...which is the status quo and what new drupal developers are restricted by..which is the status quo.
For example, I think there is scope to have an "in the wild" listing of modules with decent descriptions (good point btw) and a take it or leave it option for drupallers who understand that the modules are not officially maintained or comitted to the drupal contributions folder.
there is also scope to have a "being rolled" listing. So a drupaller who needs certain functionality and is thinking of rolling their own can check a simple listing on drupal.org of modules in development, or orphan modules (modules for older versions that haven't been upated).
At the moment, to deduce the above is very time consuming and is indicative of the general scattering of the Drupal community. Planet Drupal is good for people who have time to trawl through the updates that are fed in, but, I agree with you and think a more cohesive approach should be acknowledged and introduced.
I agree with your point about installation and AFAIK, that is a work in progress...so we should see new more simple installation routines in future..and hopefully an easier upgrade procedure as well.
Anyway..thanks again for chipping in. Judging by the amount of responses, I'm not alone in my concerns...so I think a mini-manifesto or plan of action cum-proposal should come out of this thread, taking on board people's concerns and ideas...which is something I don't mind volunteering to do if it will help increase that cohesiveness you pointed out.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
I haven't read all 184 comments...
...but yes, Drupal support and documentation is way too scattered, which makes Drupal almost impossible to use if you're not a hardcore PHP coder.
I know how to copy paste the occassional PHP code snippet and understand the general logic behind it, but for a non-coder it's very difficult to figure out what keywords to search on and what question to ask where when the answers are hidden in a thousand different places.
BTW, IRC channel?! Internet Relay Chat? International Rescue Committee? Innovation Relay Centres? International Relations Center?
Aaarrrggghh
I don't agree.
Drupal support and documentation are not too scattered:
Drupal documentation is, by far, the best documented OS I've ever seen.
Drupal support can improve, yes. Forums at Drupal are just over loaded but not too scatered. With the new search functionality that will come with 4.7 this issue will be mostly solved.
An exemple: I tried to find, again, a post I came across just a couple of days ago, where a Drupal administrator was saying how happy he was with Drupal. Drupal is flexible and powerful, he said, and not so difficult. The best of his post was the fact that he installed and/or administrated more than 100 drupaled sites without the need of writing a single line of code EVER.
This is not just an example of the difficulties of finding the right info needed from the forums but an example also of how easy is to use Drupal.
In any case, the point of this thread was that community, developers mainly, might be getting too scattered, not the support or the documentation.
If you find your self lost into the forums look at the handbooks. You might find what you are looking for.
---
Robert Garrigos
Personal site:www.garrigos.org
Admin of: www.escolasafa.info - www.societatbach.org
It doesn't matter
robertgarrigos, I don't care about your opinion on this subject. I'm just letting Drupal developers know that Drupal is too scattered for me as an average user. What they do with that is up to them.
After wasting three weeks on Drupal I'm cutting my losses and going back to Nucleus, that I had been using for the last couple of years and can do basically the same things Drupal can, but with a whole lot less crap.
The Drupal "community" is full of it...
Before you go..
Hi Peter,
Just a quick one to say thanks for your input. much appreciated..
Sorry to hear you are deciding to drop drupal, but, I just wanted you to know that there are some members of the drupal community who do listen to constructive criticism. I'd feel even sorrier if you went away having a bad impression of the "community".
As a Drupal user for a while, I felt compelled to raise this thread as a discussion point and judging by the response, I'm not alone in being worried about how the project is evolving.
Ironically, it's people like you who take the time and effort to give their two cents back in on how to improve the project that are, imho, crucial to a useful community and a better project.
I notice that the Bryght.com guys are driving some useful discussions and issues with the drupal project which might help matters. I was just reading the bullet points from the amsterdam Drupal conference on their site. I couldn't find much on drupal.org but on top of the drupal conference notes, they appear to have some good drupal documentation that's not on here as well. I'm not sure if this is an indication that the general scattering of the Drupal community is nudging it towards a more commercially driven project or essentially splintering Drupal, but, the bryght.com site is quite good as a drupal resource.
My main worry is that the more drupal.org leaves users feeling the way you do, the more demand there is for a pay-per-help or commercial solution. There has been a stark increase recently of users either dropping drupal, begging for assistance or offering money in desperation for assistance. Which is a pity as it discourages people with good ideas, good documentation and general expertise to contribute openly and increases the demand/opening for a commercial spin-off.
Anyway, sorry to see you go and the best of luck with Nucleus. Hopefully you'll drop back and try drupal again at some stage.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Suggestion
Thanks for your understanding Dublin Drupaller. I know I have been too blunt every now and then on this site, but I hope that that kind of users feedback will help nudge Drupal in the right direction.
I wouldn't call Drupal a CMS. It misleads non-coders. I have some general idea of what PHP does from working with Nucleus, but Drupal requires hard coding to do basic things. Drupal is more like a development platform or whatever.
In another thread Zach Harkey pointed to this site with a pre-configured school class CMS based on Drupal available for download. I haven't tried it, but my first impression is that it could be a more fruitfull direction for Drupal:
Forget about the scattered community and lack of documentation, leave Drupal.org for the hardcore developers, but get "third parties" to develop user friendly, out of the box CMS for specific tasks or communities - Drupal for blogging, Drupal for political activist networks, Drupal for business websites, Drupal for e-commerce, etc.
Some of these could even be commercial. Drupal should put a program in place to encourage this kind of third party development while preserving the integrity and cohesion of the basic development platform.
interesting suggestion..
That's an interesting suggestion Peter.
Following how linux evolved as a project was suggested recently on the forum here, which is not unlike what you're suggesting, I think.
I think the problem at the moment is that the project is at a half-way-house stage, i.e. it's still (just) within reach of non-php coders while at the same time, it's quite a complex websuite application framework.
Not unlike a Kit-Kat, which doesn't know if it's a biscut or a bar.
I'm not experienced enough to know whether what you're suggesting will work for Drupal or not..but it seems it's already veering towards that.
My uneducated guess is that Drupal.org should be extended to include, rather than exclude that splintered and application specific development. i.e. I think the Drupal project would be stronger if the modular add-ons and documentation/support development - which has worked extremely well with other, similar projects - was centralised rather than scattered.
Sadly, I notice that a lot of moans, gripes or constructive suggestions are shouted down in a defensive, or sometimes in an offensive manner. Which doesn't exactly help and increases a gap of "ownership" between the community and a few veterans. On the flip side, according to bryght.coms drupal conference notes, there are a lot of improvements on the way that must be taking up a lot of the core developers time so they may feel stressed with the pending release of 4.7.
Fingers crossed that we see less and less users frustrated, peeved or offended and more users thankful and encouraged to contribute back to drupal.org.
Anyway, thanks again for taking the time to give a considered opinion.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
The challenge
...is in keeping such a distrubution or fork up to date as the core develops.
Part of the problem these days is that the web is changing rapidly, and Drupal is flowing with that, perhaps more so than other CMSs.
Nevertheless, there are some distros out there doing just what you mention, including CivicSpaceLabs.org (Drupal for communities and political activist networks) and Drupal for Artists (for artists, musicians, etc.).
Drupal for bloggers languished due to lack of development. They forked the code, and suffered for it.
Laura
===
pingVision • scattered sunshine
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
totally agree Laura..
The pace of change is daunting and there is a significant challenge in keeping the code and functionality up to date. In the same breath, I think that my initial post on this thread was pointing more towards the need to keep an eye on how the Drupal community is evolving and developing as well.
There are fundamental functionality issues with Drupal.org that are being looked at - in particular the forum and search facility which have been mentioned on here a few times - it's not rocket science to notice that the support forum is failing as a "knowledge base" and has turned into a "knowledge dump" of sorts that is difficult to navigate, hunt down answers and has a lot of repetition. The online equivalent of an information land fill.
It's becoming a place to avoid for experienced Drupallers who prefer to contribute to their own sites theme folders, documentation, tips & tricks blogs and even modules.
Turning that cultural trend around is tricky. There is an opportunity to coincide the launch of Drupal 4.7 with some new initiatives. In my spare time, I'm trying to compile a list of ideas and recommendations from this thread and from general observations, but, it's unlikely that will be done and dusted before 4.7 is unleashed. Which is not the end of the world.
Ironically, my lack of skills to be able to help with developing the code may help - it's all hands on deck to try and get the Drupal 4.7 code is as clean and good as possible, so I'm limited to looking at other, more cultural aspects.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
The developers are focused on 4.7
Another issue that became clear to me at Drupalcon and Barcamp last week is that the majority of people developing Drupal core are 100% focued on 4.7 and its modules, and not on 4.6.* and its modules. The pace of development is staggering, and the depths to which 4.7 is being reworked to provide a significantly better Drupal is impressive. Furthermore, for the first time, the Drupal community has spoked directly with people like Rasmus Lerdorf (PHP creator) and David Axmark (MySQL co-founder) about how to best leverage their technologies. We're going to see better performance, better security, and truckloads of new features. Usability hasn't been forgotten either; we had several sessions dedicated to the issue.
Contrary to the the title of this forum topic ("...too scattered"), I believe that the Drupal community is coming together as never before, and growing wildly. If there are more sources of Drupal info appearing etc., that is to be expected, of course. The real question is whether this is happening faster than the Drupal core community and Drupal resources on this site are growing. If Drupal.org and its community are growing faster (which I think they are), then the Drupal community is becoming less scattered.
The feeling among key developers and proponents is that people and their resources and efforts are moving towards each other, not away.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
thats precisely what has me worried..
That's precisely what has me worried, Robert.
There appears to be a micro-community within the main Drupal community who think that all is going swimmingly, which, of course, it may well be...I just beg to differ.
The new release dates will naturally draw the core developers together to focus on the tasks in hand, but, there's a sense that once that is done, they dust themselves down and start looking at the next version.
Sizing up the next hill to climb, so to speak.
Which is totally understandable...that's the fun part of development..coming up with new ideas, creating proofs of concept and following them through to fruition.
Unfortunately, the boring bits of bug tracking, patching etc. leaves a trail of confused and more recently, disgruntled users who don't have the same depth of insight, nor the same awareness of what's going on with the code because they don't frequent the IRC channels or off-site discussions.
Perhaps it's because this mini-community is generally living somewhere else or they are too busy with their heads stuck too deep in the code to notice. Perhaps not.
I'm speculating of course but there has been a stark increase recently in begging for help posts or users so desperate they are offering to pay for assistance. Ditto for off-site development (in the wild modules, documentation and guides).
My gut-feeling is that there is a growing gap between the "key core developers", as you put it, and the rest of the general community.
Off-shoot sites and in-the-wild development is happening more out of necessity. Not out of a natural progression that happens with a growing community. The result is that great ideas, better documentation, tips & tricks and innovative modules are being lost unnecessarily and the general community is being scattered.
There's a tipping edge that Drupal is approaching where it's smarter for some to contribute to their own off shoot sites than it is to Drupal.org. When more "I'll pay you to help" desperation posts start appearing, the larger the incentive to hold back and keep the "good stuff" for yourself.
This discussion has given a lot of constructive food for thought and I'm hoping to come up with a concise version outlining the main nuggets & suggestions that might actually make a positive difference.
I hope that makes sense...and there's no need to come across so defensively. You are right, I did use the phrase "scattered" in my initial post...but, I also used the phrase "constructive discussion point" in the same breath.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
There are infrastructure plans
Much of the Drupalcon discussion was about infrastructure and how to scale it to better support the needs of the community. I gave a talk on how to make the patch queue more effective. Others took other interests and promoted them. Things will evolve and change.
Make that summary of yours --- I'm sure it will be useful. But in the end, I think the health of the project as a whole is really great. Yes, I've noticed the disgruntled users, but I'd like to see them try to have better luck with Struts. People are trying as hard as they can to make Drupal rock. Your imagery of the developers with their heads stuck in the sand only applies to a sub-group of developers. Many developers are working for clients who need very usable features in Drupal, so these developers are being pushed to simplify things and flatten the learning curve.
It's a large ecosystem. Much of the "Drupal community" doesn't show up here at Drupal.org at all. There are whole companies with a dozen or more developers that work exclusively with Drupal that never even bother to say "hello" in these forums. Your conception or my conception of what Drupal is can only be a small microcosm of the whole. How many of the Japanese Drupal developers come here? Virtually none. Why? Because they have DrupalJapan. It's just *never going to work* to try to insist on centralizing things. It's probably not that important in the end, either.
It's been an interesting discussion, but I refute the "Sky is Falling!" feeling that some have had and expressed recently.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
Desperate users, clueless developers
I've been here for about a year or so, and I haven't noticed a dramatic uptick in "Help! I'll give you $20!" posts. Those have always been around.
What Drupal HAS seen is a dramatic rise in the number of less experienced users who are initially excited but quickly sour because Drupal's potential for complexity outpaces their experience and knowledge of PHP and other web technologies. That does not mean that Drupal is perfect and needs no work, just that there is a new group of users flooding in with dramtically different expectations.
It's worth noting that the developers who are part of the 'core' of Drupal aren't there because they have some sort of propeller-beanie-wearing love of complexity and needless tinkering. They use Drupal day in, day out for their own site building tasks as well. If there's a different set of goals and expectations, it may be that Drupal is evolving into a more powerful tool, and new work will have to be done to put a friendlier face on certain aspects of it.
I'm not sure, though, that the developer community is in and of itself fragmented. At least, any more than it always has been.
--
Jeff Eaton | Click Here To Find Out Why Drupal "Sucks"
--
Eaton — Partner at Autogram
Laura s -- my company set up and distributed
the site that you refer to in your post. The site we set up is not a fork. As I explain on my web site, and in the News/Announcements section, our goal was to set up a site that was usable out of the box and demonstrated some of what is achievable with an unmodified Drupal install -- ie, someone could set this up with no programming skills. We also included documentation that explains some of the choices we made in setting up the site.
We were trying to provide a resource for teachers and people who were learning Drupal. We have received some pretty positive feedback.
As far as maintaining this site, the code has not been modified, so it should follow a pretty standard upgrade path. What we have created does not compare to Drupal for Bloggers -- our site is intended to work in support of people learning Drupal while meeting the needs of educational users.
-------
http://www.funnymonkey.com
Tools for Teachers
-------
http://www.funnymonkey.com
For the record
I did not refer to your site. In fact, I have to confess I've not looked at your site before just now.
My point was that even a distribution runs into challenges on the upgrade path, as anyone who's used CivicSpace and had to wait for the latest Drupal features will know. (I love CS and feel the upgrade delays are worth it, so please don't get me wrong here.) And my secondary point was that the kinds of packages PeterLucas was wishing for already exist.
Your project looks very promising and I'm glad you took the time to highlight it here.
Laura
===
pingVision • scattered sunshine
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
I'm sorry but
you provably missunderstud my comments. I do care your opinion although I might not agree with it completely.
Good luck.
---
Robert Garrigos
Personal site:www.garrigos.org
Admin of: www.escolasafa.info - www.societatbach.org
I don't think he was having a go at you directly..
Hi Robert,
for what it's worth...I don't think he was having a go at you personally - there wasn't anything particularly inflammatory in your reply to Peter. I think he was lashing out at the community in general out of frustration.
I received an email earlier from a veteran drupaller who mentioned that Peter is a regular poster since joining a few weeks ago and for some, is a thorn in the side of the forums with the way he voices his opinion. Having looked at a few of his other posts, I can understand how he may have gotten increasingly frustrated and generally more, as he puts it himself, abrasive.
So, I don't think he was having a go at you directly..more venting his frustrations at the "community" in general.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Don't take it personally
Yes, no one should take my comments personally. My comments were to report on my experiences with Drupal, both to try to get issues solved and give feedback for whoever's willing to listen. Frustration and anger were part of my experience.
Of course you as Drupal community don't owe me anything. On the other hand, I don't owe the Drupal community anything either. If Drupal doesn't work for me I'll just quit using it and go somewhere else - as I have done.
The attitude of a lot of Drupal insiders seems to be that Drupal can do no wrong and if any user has problems with Drupal it's because they lack skills, aren't trying hard enough or don't respect how Drupal is the New Paradigm in everything CMS.
Good luck with that...
Thank Dub for the healthy discussion
Any discussion that generates this much interest and passion must be worth having.
As for those who aren't pleased with Drupal developers thinking that Drupal is the best: I would be hesitant to spend much time learning this software if the developers didn't have a sense of pride in what they were creating.
no thanks needed bomarmonk...
I wouldn't have bothered raising this discussion if I too didn't feel that Drupal was worth it.
The point of the thread was not really to have a go at the code...which is superb and very highly rated by many more experienced programmers...it was just a red flag of warning that while the drupal developers are frantically moving from version A to version B at breakneck speed and at a staggering pace, it's leaving behind a trail of problems with users that don't have the same indepth knowledge or programming skills.
Drupal.org hasn't changed at all since I first started using Drupal. Apart from a few minor changes and new links, the community doesn't seem to be getting the same attention as the code.
It feels sometimes that the core Drupal coders are just barely visible over the horizon, smoke rising from their busy keyboards as they tattle away creating the next version. They come into view just after a version release when the first raft of bugs and issues are discovered and then shoot off again into the sunset when the majority of those are nailed to work on yet another new version.
There' s nothing wrong with that, but, it creates a gap between the experienced coding community and the rest of the user community - who know that great work is being done...but are jaded, frustrated, stumped or simply not technically proficient enough to tweak or twist the code to suit their needs.
That gap also creates a situation where the drupal.org forum is a place to avoid, rather than a place to converge for developers. Who don't want to deal with criticism (constructive or otherwise) or dumb questions. Preffering to work away on new exciting developments.
That further increases the gap which leads to spin off sites, spin off distributions, spin off development, spin off documentation and all the alarm bell indicators that - I have outlined already - points to a dissolving community and scattered project.
The end game of which is, inevitably, a fork to a commercial project. And once that happens.....
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Dear Peter,> The Drupal
> The Drupal "community" is full of it...
I know you must be frustrated... but "tell off" an entire community just because you didn't find what your looking for is not mature. What would we do if everyone had the same spirit and said something like that ?
You don't owe us anything... but Drupal support has come a long long way...
The Drupal community is getting better every month. It's inevitable, since those willing to give professional or free support is increasing all the time.
P.S.
I opened a thread here to where everyone can share their Drupal Wishes. Drupal Pro can browse it and get an idea of what to offer...
Open source is not God
That's exactly the kind of stuff Drupal is full of.
To the true believers open source software can never do wrong, because it's created by "the community" and constantly enhanced by "the community". All commercial or packaged software is deemed evil, but open source is beyond criticism because it's the will of the people or something.
It's a myth. Linux is only succesfull up to a point because Linus Torvalds ultimately decides what goes in and what doesn't. Drupal seems to lack focus and it's not inevitable at all that it will get better over time.
I know it's expected of users that they buy into the open source religion and show the correct deference. I don't do that. It's just software! It has to work, that's all I care about. I'd even pay for it if it does.
Yup, you're basically right
Hi PeterLucas,
All your points are right except "Drupal seems to lack focus". You see, we have our Linus, and his name is Dries. Dries is a smart chap who knows a hell of a lot about software, and also knows what he wants out of Drupal. Drupal is community building software. That is the focus. When people have difficulty making it do other things, well, that's probably because they're trying to do other things with community building software. So Drupal has a focus, and it steadily moves forward in this direction. It's probably a problem that so many other people want Drupal to have a different focus (be the best blogging tool, be the best forum tool, be the best image gallery, be the best coffee maker...), because when Drupal falls short in some use-case that it wasn't initially written to handle, people complain. I just feel it is a testament to its strengths that people use it for so many things.
cheers,
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
Better marketing and explanation
The problem we have seems to be in terms of marketing. Peter had two main expectations/assumptions that were not met:
What do you think, Robert? Can we analyze this and the other complaints lately from a perspective of what we need to do differently to inform them about Drupal?
Absolutely... we have to.
I know that Dries has been thinking a lot about how to move the community forward, and I expect that some of the ideas and decisions from Drupalcon will start to surface in the next weeks. Many of these will involve streamlining Drupal.org and making the infrastructure (technical and human) more robust. Members like Peter expressing their experience so clearly is very helpful when making decisions about the direction we need to take things.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
ehhh....caution
I'm not sure that directly basing how to improve Drupal on the vehement statements of those like Peter Lucas is the best approach (for instance, I'm not big on the "squeaky wheel gets greased" outlook). This tends to lead us down the path of fixing Drupal to suit those who complain the loudest. Not a good precedent. As we all agree, Drupal is not for everyone--different CMS's and communities suit different needs--and IMHO, Peter was probably one of those people. So I suspect we need to have two goals:
1) Improve Drupal/drupal.org for those whom Drupal is the right choice.
2) Help those who are debating on whether to use Drupal realize when it is not the right choice.
In working on these goals, we probably need to more clearly define who is the right audience for Drupal, something that I think is sort of done in marketing materials, but those are all constructed in an attempt to encourage people to try Drupal in a very positive way. And there is the schism between Drupal is for developers and Drupal is for users. The community has to come together on this and make a clear decision who the audience for Drupal (and drupal.org) is.
This is just the writing teacher talking. Defining clearly the target audience makes it much, much easier to make the right decisions, whether it be composing a text, building a website, or improving drupal.org for users.
good ideas
some very astute observations there Cel. And I totally agree, the marketing/communication of Drupal is quite good at the moment, but there is room for improvement.
the main thrust of this discussion touches on your thoughts about drupal.org.
At the moment, after someone reaches the adoption stage, they fit into one of two classifications that make up the Drupal community:
1. Contributers
2. Non-contributers.
I.e. after adopting Drupal, some return to drupal.org and contribute in the form of help to others, patches, themes, modules and/or handbook pages. Others don't.
Within the non-contributers side of the Drupal community, there is a growing sub-community which is essentially a break away or spin-off community. i.e. people who want to contribute back, but, are unable to for a variety of reasons.
This could be a superb theme that they maybe willing to share, but, are daunted by the contribution process.
or it could be an incredibly useful module that ends up on a distant site somewhere as a ZIP download.
Or it could be a useful "Drupal tips & tricks" blog that could sit alongside the handbook very easily and simply, but, instead is at a distant site somewhere.
Or it could be a great handbook that is more valuable to have on a company site selling drupal related services rather than drupal.org
Within the contributers community there is no default meeting place. There are a few, including drupal.org, IRC channels, conferences and email. So we end up with a few contributers working on the exact same, or extremely similar module. Or worse, we see off-site, commercially weighted, development.
So while you do have a point about the marketing and helping potential drupal adopters making their decision, this discussion was more about the post-adopters....those at the pre-adoption stage.
I notice from Bryght.com that there are some initiatives that look positive in improving the community and drupal.org so hopefully we will see drupal.org returning to be more of a community hub than it has become and some form of contributions section to cater for those great ideas, or great themes, tips/tricks blogs that would cater for those who want to contribute back, but are unable to for a variety of reasons.
I'm not suggesting we change the current process or unsettle the core developers who are well used to the existing process. I'm just suggesting an intermediate contributers area where "in the wild" themes, modules, tips & tricks, handbook pages etc. are contributed to Drupal.org rather than on some distant site.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Let's be positive
I don't want to repeat my self, so these are my thoughts on how to move the community forward: node/34977#comment-63169
---
Robert Garrigos
Personal site:www.garrigos.org
Admin of: www.escolasafa.info - www.societatbach.org
My expectations
I chose Drupal because I'm trying to build a social network site. You can see the partial result of my attempts here. This will eventually be replaced by a Nucleus version.
I got in trouble because most customization requires hard PHP coding or thorough insight in the inner workings of the system. For a non-coder it's not transparant what calls what, how the different elements hang together.
I gave up when I couldn't figure out how to make the group pages more like attractive homepages. And the Event Module turned out to require its own additional access module. I thought it was a bad sign that apparently adding new elements or modules can create new problems in Drupal.
Nucleus is designed in such a way that you don't really have to know PHP to understand what's going on. A non-coder can customize a lot by copy pasting code from one place to another. It's all very transparant.
In Drupal the advice I got when I asked questions about customization ranged from 1) get CivicSpace to 2) keep it simple, use the provided themes to 3) learn how to code and write it yourself.
So, I wasn't looking for a blog and I wasn't expecting an out of the box solution either. I was expecting a CMS that would provide lots of flexibility without hard coding skills - which in my understanding is the entire point of a CMS.
BTW, in response to mpamphile ('Who ever said such a thing ?') see this post. Apparently I'm not the only one bringing up this issue.
I would like to see something like this before one dives in.
As a "visitor" from the Typo3 community I can say that you have hit some valid points here. typo3 is still a mailing list type community and coming into a forum like Drupals is like visiting a foreign country.
Expectations of what Drupal can do is also right. I was convinced by someone that Drupal might be able to stand in for Typo3 in a pinch. But so far I can find nothing that would convince me to give up having learnt Typo3 and replacing it. But I may add Drupal into the line up. But it is hard to see where it would fit.
When doing a small businesss site I use mambo and now Joomla. Because I can just give the site over to the owner and the support need is minimal. For larger sites where there is an in house developer/webmaster Typo3 fits the bill.
The problem I have with Drupal is that I can not give a class or seminar and have it satisfy the customers needs for a long period. This is because Drupal does not seem to work the same way from version to version. This was an unexpected thing that will probably make my use of Drupal more like a hobby than a business asset.
I just saw a thread where a site was built for teachers and a tutorial of the project was given. How long will something like this last? One version? two? a point? (Mambo changed on a point version recently, not nice.) Perhaps this could be worked around by not upgrading but I am getting the feeling that this is not recommended.
Well my point is it would be nice to know somethings up front.
Who ever said such a thing ?
I think your bringing a fight that probably started somewhere else... No one is saying that Open Source should be worshiped...
I love commercial AND open source software and there is a place for both.
At least we both have one thing in common , we are willing to pay cash for affordable services.
I created a Drupal Wishlist/brainstorm list item over here: http://drupal.org/node/34977
Please post a wishlist of what you want to see in Drupal, Drupal freelancers, Drupal.org or the wider Drupal community.
P.S. This thread has 2 pages now !!!!!
http://01wholesale.com
The pager is now broken when
The pager is now broken when trying to use it with recent posts. It just goes to the first post and wipes out the "new" post session cookie. So clicking on "new" does not work anymore.
This bug is probably a direct result of the 200+ posts. The limitations of Drupals forum module are starting to show.
It's a bug relating to
It's a bug relating to Drupal's handling of pagination, actually. It's not a factor of the thread having 'a lot of posts', but simply that the number of posts is high enough that it spills over to a second page. (If the forum is set to show 15 posts per page, then the bug will occour once there's 16 posts in the thread)
The 'new' link doesn't take into account that there's more than one page of comments. It gives an anchor to the comment's number, but the actual page that it links isn't the one where the new comment resides.
I linked a couple related items here:
http://drupal.org/node/30161#comment-51616
Thanks,
Thanks,
I could not even find your reply and started another thread to try and get more information about this. With this known I think that I will start supporting those efforts to integrate Drupal with another forum package.
It is strange that both Drupal ,Typo3 and several other cms's suffer the same shortcomings in their built in forums or default extensions. Given that a forum is the nucleus of building a community. one would think they would have done better. Especially when most claim or advertise "community" as being their strong point.
Without a strong and working forum a CMS is "portal" software not "community" software.
there are discussions about that..
Hi Nathandigriz,
there have been some discussions about improving the drupal forum and it seems that the development of modules that allows third party forum integratation forums has moved quicker than the built in forum. It might be worth checking out the flatforum module/theme which helps to make a Drupal Forum look more like a standard forum.
I think everyone is aware that stuff like the forum and search could be improved and judging by the discussions, 4.7 will have a lot of those improvements.
You are correct, a solid Forum is an integral part of an online community, but, while I think the Drupal forum has room for improvement, I don't think it's fair to diss Drupal because of that. I actually like the Drupal forum...if the search was improved, it would make it more efficient as a knowledge base. That's a work in progress with Drupal 4.7. And webchick has started a discussion on how to improve it.
For what it's worth, I was working on integrating a slightly different style of forum into Drupal.....more a mix of a message board and forum and I have put that on hold until Drupal 4.7.
The bottom line is that, judging by the areas of development, after Druapl 4.7 users will have a choice of using the new improved Drupal forum or "plugging in" a third party forum using the growing number of modules that allows that.
So if the new Drupal forum isn't for you, at least you have the option, which is a very positive scenario I think and strengthens Drupals capabilities rather than weakens it.
I hope that makes sense.
EDITED: Incidentally, you have given me an idea that would help improve drupal.org, i.e. an "IN DEVELOPMENT" board...one of the problems at the moment is that unless people have time to visit various sites or IRC channels, it's very difficult to keep up to date with what's being developed or what other people are working on.
A simple node that allows developers to post brief "this is what I'm working on" type notes would be extremely useful. It would be split into 1. core and 2. contributed add-on modules so you could see, for example, that the Forum is being improved..or that someone else might be working on the same idea.
There is a MODULE DEVELOPMENT FORUM category..but, it doesn't really work as a quick list of "what's in development"..there is a developers email but that is also very clunky and difficult to navigate through the archives.
Anyway. Thanks for chipping in your opinion. I think you're a little bit unfair picking on a few shortcomings in the Drupal forum..overall it's a superb tool and is improving all the time. The purpose of this discussion was trying to identify how best to develop the drupal community.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
Well since I am trying to
Well since I am trying to find a vBulletin replacement to be fair I will list built in forums that are really lacking or just suck.
Typo3
Joomla
Plone (cmf board pretty much sucks)
xoops (hacked?)
Of course there are more but these are the ones that standout.
I think part of the problem is that the projects start out using an email list to build the community and the community effort never falls upon the online forum.
how to define a focus from scattered efforts and points of view
I just posted the following: http://drupal.org/node/36906
I decided to cross-post under this topic, since I think the book offers important insights to open source projects. In reality, I think the book offers an all-encompassing general theory that embraces open source, as well as market economies, Who Wants to Be a Millionaire, Google searches, and the full use of individual human potential in a collective process:
"I'd like to recommend the book The Wisdom of Crowds by James Surowiecki. It mentions Linux development as an example, but more important, it provides specific criteria that determine whether collective knowledge-building projects like open source software are achieving the best decisions they can, given the collective knowledge of a broad set of people.
Here's a nice summary from one of the editorial reviews on Amazon.com:
'If four basic conditions are met, a crowd's "collective intelligence" will produce better outcomes than a small group of experts, Surowiecki says, even if members of the crowd don't know all the facts or choose, individually, to act irrationally. 'Wise crowds' need (1) diversity of opinion; (2) independence of members from one another; (3) decentralization; and (4) a good method for aggregating opinions. The diversity brings in different information; independence keeps people from being swayed by a single opinion leader; people's errors balance each other out; and including all opinions guarantees that the results are "smarter" than if a single expert had been in charge.'
I would only caution that the book carefully defines these criteria, to show when and how these criteria are met by situations. For instance, not all decentralization automatically leads to wise decisions, although decentralization is necessary for them.
I'd be interested to hear of other sources of open source philosophy. The key contribution of this book is that it points toward a general theory of collective knowledge that is broadly applicable and empirically verified. The addition of empiricism to speculative or principled philosophy about open source seems important.
Now, I'll be quiet and go back to chapter 8 of Teach Yourself PHP in 10 Minutes and finish that book, so I can start to be of real use here in the way I would like to be... ;)"
thanks for that..
That sounds like an interesting book. The main thrust of this thread (I started it) was focussed on the fact that Drupal meets those four criteria but those four criteria are not being implemented outside a core group of experts.
In other words, the community structure and hierarchy has worked to get Drupal to the point it's at, but, to move forward, there needs to be a mini culture change so that collective knowledge is harnessed rather than what is happening at the moment rather than scattered..i.e.
I could go on..but I assume you have read this thread and have the gist of the warning flags I'm trying to wave.
Thanks for posting that book title and summary..it sounds interesting.
If you're looking for some interesting resources on the philosophy of communities..it's worth checking out Noam Chomsky's lectures and work. There is a dedicated bitorrent site where you can download his lectures and talks for free. He's primarily a linguist (Professor at MIT) but he does a lot of work studying the philosophy of communities and in particular the democratisation of communities. It's not specifically about open source tech, he has a serious problem with the USA establishment..not in a Michael Moore sense..Chomsky is more cereberal and less sensationalist..but, his musings on how communities work is interesting..in particular the democratisation of communities. Which is intrinsically related to how open source software evolves.
It's more philosophical than dissecting the practicals of how linux evolved, for example. But worth checking out if you're interested in that area.
What's interesting to note is that this thread, since it started, has been one of the most replied-to threads on the Drupal forum. There are a lot of great ideas in here on how we can tweak the Drupal community to make it more fluid without compromising quality control and a lot of enthusiasm/acknowledgement that things could be improved.
So the desire for change appears to be there within the community, the hows and wherefors need to be thrashed out now, so the timing of your recommended reading couldn't be better.
There is a danger of analysis paralysis in situations like this..but I think it's worth delving a little deeper.
Dub
Currently in Switzerland working as an Application Developer with UBS Investment Bank...using Drupal 7 and lots of swiss chocolate
diversity, independence, and methods to aggregate opinions
I think those are the three criteria out of the four mentioned above that open source projects would seem to benefit most from.
Independence means that when one's opinion is given, it is done without regard to others', so dissent is encouraged, since we all have "private knowledge" that others do not have or see the significance of. In contrast, in "information cascades", groupthink, or actual suppression or pressures against contrary views, this criterion is not met. (Intellectual) diversity is largely met, when the composition of the group is not homogeneous and when they have not interacted to a point that they have begun to influence others to adopt more and more similar views ("conventional wisdom" as opposed to collective wisdom). In addition, independence and diversity allow very different alternatives to be proposed.
Methods to aggregate opinions that the book recommends are similarly independent. There is no need for consensus-building techniques and extended debate. Rather, if there is a good set of diverse alternatives and the crowd is diverse and independent, then a blind survey can do the trick, where the responses are taken as-is, the winner often being the optimal choice. (90+% of the time) Sometimes, depending on the nature of the problem, averaging the responses or applying some other algorithm makes sense, but this is not to manipulate the results. Rather, it's like guessing the number of jelly beans in a jar. The collectively-intelligent result, according to the book, is the average of all the guesses.
That's what I gathered from the book, anyways. I won't try to define practical applications of it for Drupal, since this is a long post already.
Fascinating thread...
Thanks to everyone who has posted here, it's been well worth reading this thread. Dub - you're a true diplomat! ;)
I'm quite new to the Drupal community, we've only set up two sites using this CMS so far. I did encourage one of my developers to donate a module back,, especially as there seemed to be others looking for the same thing.
After a lot of searching, we applied for a CVS account but haven't heard anything back. We don't want to help with the core code, just submit a module or two which other's might find useful. We're your typical web agency type user, who wants to donate back some of the work they have done for paying clients. In terms of welcoming modules or contributions, there's quite a lot of work to do.
We've done this sort of thing over at osCommerce and their contribution section seem to manage quite well without all these hoops. Maybe people are just thinking about this too hard? Everyone knows modules may not be supported and may break after updating. I don't follow the argument that people will turn round and blame Drupal. Wordpress/osCommerce etc - they all understand about modules, especially when each one is linked to a forum thread.
It does seem that a lot of modules are spread out all over the net with no central /searchable list. I don't see how that helps anyone and it's not hard to see a need for a 'drupal module' site. As Dub suggests though - maybe that sort of thing would be better housed here on drupal.org?
P.s. On the forums - I'm 100% in favour of putting the email notify (any of them) on here.
Thanks