By zero-zero on
Hi,
For weeks I was developing a website using the Drupal CMS. I sumarize my experinece on my blog at http://www.tagworld.com/motoras hopping that it may provide some valuable information for drupal coummnity. I would be also curious what other people have to say about my thoughts, (or if there othe rpeople who had the same problems) and I will be very glad if at least few of my issues will be approached in the future.
Looking forward for a better Drupal, and waiting for your comments
Romulus.
Comments
Stupid popup
Just need to get this off my chest, before I even read your page:
- Annoying popup
- Annoying popup tells me I'm using the 'wrong browser' - one of the worst titlebars I've seen this year...
/me enables popup blocker
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.
good comments
these comments were so good I wanted to post them here. (also they would not display in konqueror only firefox)
My Drupal experience
Mar 17, 2006
My Drupal Experience – The Good, The Bad, The Ugly and My Thoughts
Those are the conclusions after my experience with Drupal in developing my soccer portal zero-zero.info. I am a software developer with a 6 years of experience in OOP development most of them with Java. I am still paid to do Java programming and I love Java. However because there is no a valuable CMS solution in Java, and because the java hosting is expensive, I decide to look for something else when I planned the development of my own soccer portal. After some search and comparisons I chose Drupal because it looked to me to be the only suitable open source available out there. My site is done(so any soccer can came to join us) but my experience with drupal was mixed. I will try now to summarize my experience with Drupal, more exactly with drupal 4.6.5
The Good
*
I don't believe there is out there a free CMS with so many features as drupal
*
The installation was quick and painless (I don't thing that a wizard is absolutely necessary)
*
I love all the anti-spam features, the badbehaviour module and the troll module for IP block, but remains to be seen how powerful they are
*
Organic group module this is amazing and was one of the main reasons for choosing drupal.
*
Taxonomy - this concept is very powerful. However is so bad documented that it took me weeks to realize how to used. Also the free tagging patch is a must.
*
Tagadelic I love tag clouds so I was really please to integrate this module
*
The permission system one of the most powerful out there but still need work
*
Productivity - I would need probably at least an year do develop the site by m myself
*
RSS feed is support very useful. To bad I could not make the ping module working but I am still working on that
*
The community is vibrant and often people try to help you if they can
The Bad
*
The documentation is out-dated, incomplete, hard to search in one word useless. They really can delete all the documentation that is on the site because is not helping anyone.
*
I don't believe that any kind of unit testing is promoted in drupal, I haven't seen any tests in drupal CVS and most of the modules are released with obvious bugs. For almost each module that I installed I had either to patch it or to get in code sources and make some changes to make it work. I was lucky in almost all the situations but for some modules that wasn't really necessary for my site I quit. Even most common modules did not work for me without patching them. If it wasn't the large number of features that drupal provides, I would quit using it. However during the development I made a second research trying to find a CMS better then Drupal but was no luck for me.
*
The search functionality in drupal sites returns a lot of garbage. To be able to get some decent search results on drupal forum I had to use goggle on drupal site
*
Difficult to customize – For example I hate that you can't easy provide a page by appending two nodes, or you can not customize a node display.
*
Directory view – or better the lack of a true directory view for the content based on taxonomies. I tried at least 6 of this kind of modules but no one provided a decent solution(most of them had even problems to display the hierarchy correct). I stuck with taxonomy_dhtml but I am not a big fan of this either
*
Views module – I tried to install it three times until I succeeded but it didn't worth. it. The default view provided is useless and building views prove to be a pain.
*
Banner module – is still in development and has not enough features. Very difficult to install and incomplete
*
Quiz module – or better said the lack of. These is the only kind of content which I missed in drupal. I know that this module is in development but it does not look to progress.
*
Cache not works correctly – I had to disable the cache because the site was not working with cache enabled.
*
Archive views does not allows me to select the year 2006 (I have to check how to fix that) – a classic type of bug in drupal. Even the most basic functionalities sometimes are buggy.
*
No fun. I was not smiling working on a drupal site. Interface is not intuitive menus are confusing, configuration options are bad described, not to much options for customization, not an easy way to change colors in a theme.
The Ugly
*
Organic group are not a core module so they are not full integrated in the system. They are powerful but for example not being able to define a taxonomy for a group is annoying.
*
The themes or better the lack of them. The themes are ugly and hard to configure
*
Comment are hard to maintain and the management interface is not intuitive
*
Login module never behave as you expected. Never redirects to the previous page. Logintobogan is not much better
*
I know I mention them at good but they are also ugly. The permission system is good but not flexible enough. The permission based on taxonomy terms was no help for me.
*
Downloading scripts for CVS – being forced to download files from CVS repository to update your installation is not fun and looks very insecure to me, a guy used with compiled languages
*
You can never upgrade. Once you start with a version you are stuck there. To make it work you need to do hundreds of source changes, patches, updates etc.. so you can never think to upgrade. It is far to dangerous.
*
If you are not a programmer stay away from this product. I don't imagine how a web designer can use this. You really need average programming skills to setup a drupal site.
*
Backward compatibility – The patches are usually applied to CVS HEAD which is now tied to drupal 4.7. As I said before you are forced to stuck in your initial version, and is often to no be able to benefits even for the smallest patches.
Suggestions for Future
*
Release more often. I will even suggest at least monthly releases. Every day there are fixes posted on the forum, why not benefit from them without being force to browse the forum or the CVS repository all the time?
*
Fix more bugs – there are still to many bugs in this project
*
Fix the cache – a better caching system is required. Maybe a distributed cache through memcache
*
Provide decent documentation even if we have to pay for. This even can be a source of financing for the project.
*
Improve the support – there are still a lot of posts unanswered on the forum. When a new user asks something. maybe is a stupid question but if he/she gets no answers he/she is going to quit.
*
Integrate few more modules in core - at least the organic group module must be there. Banner module is also very useful.
*
Improve the permissions system. I read the proposals about improving the permissions system and if you keep working here his is going to be a huge asset for drupal. If you can provide permission by specific content not by content type (in OOP terms will be by object not by class) that will be great.
*
Provide an easy way to generate views by appending more views in the same page – This will be a great tool in customizing the site.
*
Change/Improve the search . The search engine is not good. Maybe you can use the C version of the Lucene engine which(in Java) is a high quality solution.
*
Find a way to cluster the product – required if you want to have more enterprise deployments
*
Allow module uploading directly from the admin interface – this is a major administration problem right now.
*
Provide much more themes – even one hundred themes may not be enough for the users, so they will be able to really give to their site the look and feel which they like
*
Backward compatibility – Pay even more attention to backward compatibility. In the day in which I will be able to upgrade my site to drupal 4.7 I will remove this point.
Last thoughts
After my experience with drupal there is no doubt why java dominates the enterprise today. Besides it's more complex development-deployment cycle, the java products are more stable, more backward compatible, more flexible and developed from day one with enterprise environments as targets. However there is no free,open source java equivalent for Drupal today but as long as Drupal is so bug prone and bad documented, it still has along way to go until become a mainstream product. Also I have some concerns about his scalability.
The good news is that Drupal did is job in a short time(6 weeks maybe), in which I only worked evenings after hours. Also the product is not so buggy but I would say is not polished enough. Most of the bugs only required simple changes and where probably generated by a developer who forgot to review his code, or were caused by copy/paste
However I had a lot of frustrations during the development of my project.
I don't plan to learn PHP. I am a little scared about how messy looks so for my next personal project(which does not require a complete CMS) I am going to try Ruby.(I am just curious about all this ruby buzz) As I said first, my impressions are mixed. The capabilities of this product are amazing but it requires a lot of tunning and an experienced developer to be able to deliver a decent web application. The lack of documentation really slows you down and the risk to get stuck in the version in which you initially developed is huge.
Rome wasn't built in a day
"Rome wasn't built in a day" is the thought that usually pops into my thoughts when I read some of the complaints about Drupal. Sure there are problems with some modules. Sure new releases are slower to come online than we humble users (i.e. non-coders) would like. Sure there aren't a plethora of themes to chose from, although Nick Lewis has some dreams about fixing that problem.
My biggest hang up with Drupal is the name, "Drupal". It just doesn't generate the same emotional response as a name like "ruby" or better yet, "ruby on rails". Wow, that's a cool name. "Wordpress" even has a better ring to it, IMO, but I tried using it and found it confusing to learn and lacking in the kind of functionality I wanted.
When I consider the power and flexibility that Drupal offers, along with the active community support through the forums, I think it's a heck of a CMS, and it's FREE.
I thought Romulus offerred some constructive points. However, writing that the handbooks might as well be deleted was not one of them. People often overstate their opinion, and others jump back at them when they do. I see it all the time in my line of work.
I don't know a lick of php, but I've been learning a great deal about how to use this CMS and how to work with it in different environments. I even set up an xampp-lite install with drupal 4.7b6 on USB stick. I told my daughter "check it out, a web server on a stick." My daughter was like "what's a server?" "It's a ... oh never mind..."
So now I have "Pocket Drupal," what's it good for? I don't know. How did I figure out how to do it? From the support documentation on this site and the people on this forum. For something that started out just a few short years ago as way for some college students to share a DSL connection and figure out where to get together to drink beer, this software has come a long way.
Roger
Views?
I installed Views and everything worked and it is wonderfull!
Instructions : copy everything in your modules folder, run the sql command, and activate it.
That for the installation part. Obviously, the utility of the tool is your personnal opinion.
Alexandre Racine
www.gardienvirtuel.com Sécurité informatique, conformité, consultation, etc
www.salsamontreal.com La référence salsa à Montréal
agree
i agree with a lot of what you say. thanks for writing it down.
i'm trying to find the right directory/taxonomy solution. interesting to hear you chose tx dhtml.
i've set up www.drupalecommerce.com where people can review each module. you'd be welcome to post and vote there with what you've written. your post helps me think about which modules to use.
for me the documentation has been very useful, but more after someone (like webchick and sepeck points to it). searching often does not produce the right handbook page.
it's great you can fix the modules. they have little things that annoy me that i have to live with.
if you could submit your fixes that would be great.
again, you are welcome to submit them on www.drupalecommerce.com if the core team disagree with you about whether a patch is necessary.
i don't think monthly releases is a good idea. seems like a nightmare for upgrading. i just upgraded to 4.7.0b6, a week after installing 4.7.0b5, and i didn't not enjoy upgrading the modules.
thank you for your thoughts. I find them valuable and appreciating your taking the time to write them down.
raising money
i agree. one thing I'd like to do on www.drupalecommerce.com is raise money for improving modules and for documentation.
i spent today checking out typo3. it has backwards compability. nested groups. if you use it please do post back with what you think.
http://drupal.org/node/54042
I am on day ten of using
I am on day ten of using Typo3 and tryng to get a multilingual blog community site done. Typo3 is nice as far as having the pieces. But it seems to be geared more towards a corporate environment. Blogging , RSS and some other community functions are just not there. Finding the extensions for them is just as hard as finding extensions for building drupal. Support sucks big time! There is only the mailing list which probably has everything I need to know but I can't find it. The documentation is okay but their is too much of it and it is not searchable because it is all in pdf files. I have the Typo3 book sitting here but reading it only makes my head hurt. It has no organized example of a community site with mulitiple users. It's like reading a car repair manual.
That being said I promised to give Typo3 a full month before I decide to do something else. but right now Drupal is looking pretty good in comparison.
The biggest problem with Typo3 that I can see is that I will never be able to train anyone to run the site. It looks like it would take me a year to learn just the surface workings. Then later trying to show others would mean they would have to take the same year. There does not seem to be any shortcut method of learning. this would be fine if you have a company with dedicated web people and Typo3 was going to be the only thing run. but in a school where the students are constanly coming and going and graduating this is not going to work.
Regarding a directory module
We've got one here that works based on taxonomy.
http://www.buyblue.org/directory
You do have to use CSS to get it into this kind of two column layout but the tag structure is there and the module divides the column appropriately.
I don't really have time to maintain a module right now but if anyone wants to take that task on you are welcome to the code. I think it might even be a resurrection of something older.
============================================
BuyBlue.org
My thoughts on the post
Some serious and fundamental misunderstanding about Drupal, development and Open Source contained within that post. Looking forward to your involvement, tutorials and documentation contributions where you show us how it's done.
Checks for poster's record of support
Looking forward to seeing the poster answer the unanswered questions in the support forums because I'm looking for my free support minions and I just can't find them. And no, I'm not offering money for any.
If the poster in question would bother to help test the last of the critical bugs in CVS maybe that would get Drupal.org up to the 4.7 search code base...
Can't customize page display? That's just funny as hell. Directory module not working? That's not even packaged and has to manually be dug out of CVS.... that's so funny.
Enough... it's to funny.... I evidently have to go delete the handbook....
-Steven Peck
---------
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
My thoughts on your answer
I am sorry Steven, but the fact remains is that this is the way Drupal presents itself to a new user. I had my problems too and even though everything is contained in the documentation it is very hard to find.
Your post reads kind of like "shut up and start coding ...". Not everyone is a php coder. I know I am not, but if I have firgured something out I am happily sharing the little bits of knowledge.
Neverthless, I often read your posts and many are very helpful, but often you assume that everyone is either a php coder or not worthy of your consideration.
There are other ways to help
There are numerous other ways to help. For example, the documentation this user feels should be thrown out. What is to stop him from making contributions to it so it is useful? It seems like being a new drupal user and walking through it and making suggestions would be ideal.
I do believe that there is a documentation team working very hard to make things better.
============================================
BuyBlue.org
but...
The real challenge for Drupal is it's ease of install/use. Any time you create something with high "usability", you're going to wind up attracting lots of USERS. Not developers, but users.
Sepeck's response above is definitely all too common around here, and probably the only thing I dislike about Drupal, period: The devs are too defensive, and always play the "you don't like it, fix it yourself, and then I'll be impressed" card.
If that doesn't drive potential converts away, it at least makes them standoffish with the one group of people they most need to interact with/benefit from. On the other hand, projects that ignore their userbase do tend, eventually, to lose popularity/momentum.
My company has sponsored development on a few modules, and those improvements and bugfixes have been contributed back to the community - but none of that would've happened if Drupal wasn't something I could EASILY install on my laptop and play around with. Where does that put me, then, on the scale of drupal worthiness?
Of course, the above may not be the most sugar-coated review of Drupal, but did it outright lie about anything, or make any grievous user-perspective errors? Absolutely not. Well, perhaps the bit about the handbook being completely useless is over the top - but the general point that it is nigh-unto-impossible to sift current and out of date solutions/patches from the forums/docs/wherever is definitely valid.
Inasmuch as I'd like to see a stable 4.7 release, and subsequent Drupal.org upgrade, I'd much rather see more focus on improving the existing site for the vast majority of non-coding visitors, or perhaps always maintaining a "dev" and "prod" version of drupal.org, so that we could see the advantages of the new codebase, search functionality, etc.
In fact, keeping a dev one "version ahead" of production, but synchronized as much as possible in terms of content would go along way to alleviating the most unique complaint of the review above: backward (or is it forward?) compatibility. ;)
Anyway, it might be really beneficial to have some "official" way for non-devs to interact with the Drupal development roadmap... Perhaps add voting to bugs, or even modules, to help give the coders an idea not only of what might scratch their personal itch, but also what's in demand in the userspace (and may, in turn, lead directly to further work/cash for the devs that take them on).
All that said, I think Drupal really is out in front in terms of what I, and lots of people like me need... We just need to, you know, feel welcome - even if all we ever do is use the software. For some reason, a large contingent of code contributors seem to think that makes us "leeches", or "lazy". I just don't get it.
The roadmap...
The Drupal roadmap is what coders contribute in patches and functionality.
That truly is it. Other methods have been tried and didn't work out well.
You can help influence this somewhat by tracking the development list and helping developers with UI mockups, constructive feedback, carry through on offers to test (non-coders can learn to test I have). As you contribute more to the project, support, docs, contructive feedback you develop your reputation as you stick around.
This gets you more voice so to speak, but keep in mind, I don't code. So I am limited by that one simple fact. I have input, but it's limited to within the realm of what I can contribute. Testing, docs, UI critiques, support.
There was a huge amount of discussion between 4.4 and 4.5 that focused on UI and the results of those discussions are still having a positive effect on each release of Drupal. A lot of the participants in that discussion weren't coders, they were usability designers.
You want input, then all you have to do is get involved. Involvement takes time and commitment. That truly is it.
-Steven Peck
---------
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
Dig a bit.
Hrm. While it's probably no fun to hear negative feedback on your baby, I think Drupal would be better served by trying to find truth in his post than trying to pick holes in it.
At the end of the day, we have a guy who tried to dive into Drupal and got frustrated. Yaw, he clearly doesn't "get" open-source or (to some degree) Drupal... But there are some valid points.
One of my biggest pet peeves with open source is that a lot of criticism is met with a snippy response along the lines of "Okay, smart guy, I look forward to seeing your participation/code/tutorials/etc". By posting feedback, he IS participating.
Some users are JUST going to be users... If they make noise when something frustrates them with any details (like this guy did), then they are MORE than users... They are TESTERS (and more valuable than your standard users).
___________________________________
Tony Wright
Day2 Technology Ventures - Venture Capital for Technology Startups
I read his feedback. I
I read his feedback. I looked hard for the constructive parts of it. As he expressed complete contempt for the current documentation I can only assume he has a better way to do it that he is not willing to share or work for.
At least one of the modules he specifically sites is not even released by the developer. So, no, his comments were not constructive or useful in that regard.
For the others, I don't know php either and I contribute to the community just fine.... so perhaps start contributing docs if you don't like them. I will gladly approve good handbook pages all day rather then write them myself. If people would bother to contribute them.
I've even started a tutorial which will find a home in the handbook when I get more to it. Many people claim they are going to work on something like this. Many people start threads where they lambast the commnity in general for not giving them this for free and why does it not exist! We're obviously trying to make this harder than it is and keeping secrets... We are not!
We ask, we beg, we plead for people to contribute. Instead random people come along and tell us what the community is doing wrong. An example, Jeremy saw something about bread crumb behavior he didn't like. So you know what? He posted, got feedback and contributed a who new module and a bunch of patches to core to help make his idea a reality. So, please folks... rants = annnoying, not construcitve. Articles and posts and work (docs, patches, support help useful. Rants lambasting the 'community at large... not useful. At all.
Drupal is a meritocracy. Lots of people have good ideas. Lots and lots of people have good ideas. Active contributors themselves have more ideas then they can make into a reality. You have an idea? Please start contributing work to help make those improvements a reality.
For the record and those misinterpreting my post. I wasn't being defensive. I really thought it was funny. I will mention again, I am not a developer. I don't code. Please folks, you really don't have to be a developer to contribute constructively. You don't honest.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Still don't know php after two and a half years.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Docs fine , search is not.
The documentation is great in drupal. The problem is that you have to essentially re-read it unless you go through it bookmarking not only what you are looking for but what you _might_ be looking for tomorrow. I think when people say 'the documentation sucks' they are really saying that 'i cant easily find stuff in the documentation' which is a different matter... everyone is used to pretty high search standards at this point. I've seen the 4.7 search, and used it a bit on one of my projects .. and i really feel that this will make drupal suddenly more 'friendly'. Consider:
A newbie is looking for information on theming user profiles. He/she goes to the search ... finds a bunch of posts from 2004... which refer to an old drupal, not the one they use. They get confused, and angry , understandably , since the search really should order things by relevance and date on this site in particular, so that a problem identified in drupal 4.4 is not displayed at the top of the search results.
More advanced users have stuck with the process, because they are used to truly bad documentation for whatever reason.. taking over projects from dead/burnt out/fired/crack addicted associates at work for example. They grimly read and reread the docs, hit drupaldocs/api.drupal etc, and after a while .. they 'get' it... and so now they have in their head a map of where things are in the docs, and it goes much faster.
The newbie complains in pain and anger, because this is the best php cms available, they can see the power, but they dont know how to pull it apart, and really why should they have to? The point of api's and documentation is so that one does not have to actually open code files to figure out what is going on..
A more advanced user accepts that this is the way and endures it, grimly.
Having said all that , the search improvements coming will really help find stuff... and the docs are decent... so you can relax , the work you have done is quite good and appreciated. And to repeat once again, the search has changed in the new version.. so all will be better, if not well.
A "tree and your branchs"
Documentation has been very improved at every month since I found Drupal six months ago. Steven Peck and others herois are doing a great work in Handbooks. Searching will be improved in 4.7 version.
But in my humble opinion the problem is the "tool" used to contain the Handbooks. Book type content is eficient when the content is not very large and it has few "branchs", but your eficiency is worsened as much as more "branchs" are necessary to enclose more content.
I see the Handbooks content like branchs of a tree.
If I see the whole tree and your fews branchs in advance, each branch and what each branch contains before to go through it, it´s good, but if there many branchs and I need to go through each branch to see if there is what I need to know in the end of branch, something is wrong in design.
The Handbooks are complicated due to design. Information is there, but some content is "hidden". Several times I was surprised to found ... "voilá"... something hidden, and the new search on 4.7 version is not only the solution.
Other problem in your design it is left menu changes completely when a link is related to a new "branch". It means I "fall" in a other different branch, so my thought when it's happens is... "where is joined this branch?" I feel me lost. To build a educational material, a good designer doesn't use links over links expanding on left menu without references well fixed.
I think other problem it is mantain the content with branchs increasing each more. Book type content is not good sufficient to managing this situation.
It is not demerit to Drupal as CMS if a other tool were used to better managing and mantain the "Handbooks" like a Wiki. I think book content type is not good to these due to complexity and huge amplitude of content. There are many many branches and the material stays "hidden".
Concluding, Drupal is great, the content of Handbooks is being improved each more, the problem is design. The Handbooks don't show as magnificient is Drupal due to problems in to found the answers to our questions. More, if the replies are there and we don't found them, how to know what the questions need to be given attention? (thinking in silence).
critics not welcome
i've made comments in the past along these lines and not only got bitched-slapped, someone did some work to demonstrate what a whiner i was. but i'm not only continuing to use drupal, i'm spreading the word -- teaching a class in it at our local parks & rec. i love drupal.
but, damn, it is a major pain to use at times. and when someone offers up constructive comments as above, they should get positive feedback. if drupal doesn't take care of some of these institutionalized problems, it's going to get replaced one day. that's how things work in a market. drupal is great, but it can be done better. either the drupal community will fix these problems or another product will.
Feel free to take the write
Feel free to take the write ups from your class and turn them into handbook pages. I'll gladly approve them. You even get your name listed as a contributor and can check that spiffy box in your profile indicating you contributed documentation.
-Steven Peck
---------
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 know what I haven't
You know what I haven't figured out in over four years of Drupal? Why I should be interested in any such lengthy lists of what people like or dislike about Drupal. It is really an enigma to me. If you have looked at a few of these lists you will quickly find out that they are specific do the individual user's needs. Usually, they bitch about how hard Drupal would be to install. This on doesn't do this, but has other gripes. It is still not interesting to me, as _my_ gripes are entirely different again.
And now it occurs to me that maybe we all would have a better Drupal if we'd all fix our own gripes. I've been doing that over the years and I dare say I wasn't too unsuccessful.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Is that right
Actually I always found Drupal easier to install than most other cms. How hard can it be to copy some files and change a SINGLE file (settings.php).
Either way, I read a good article recently, that talked about how communication media like email or forums can lead to huge misunderstandings, since you don't see your communication partner and can not see that he intended to be funny, ironical or anything else.
So anyways, sorry Steven for mis-interpreting your comment.
I agree it is funny and I understand your feelings about comments on documentation, especially when it is your baby.
I am mostly happy with the documentation, once I find it, LOL.
I am unhappy with the search but since drupal.org gets indexed by google rather well I can live with it.
(And no I am too dumb to code anything better, but I still can say that I don't like it, can't I?)
-------------------------------------------------
http://www.opentravelinfo.com
http://www.aguntherphotography.com
The interesting part...
...Is that the user in question was able to, by his own admission, create a fully featured community site to spec in six weeks of evening-and-weekend spare time even though he didn't know the programming language it was written in.
Huh. I'm always startled when experienced developers botch running a SQL script, copying a file to a directory, and clicking a checkbox. C'est la vie, I guess. Most of his comments do read like someone who learns a system under the gun while working on a project. I've been there before, and one tends to find all the wrong solutions very quickly.
So, to recap: fix all the bugs, add more functionality, release more frequently, create a hundred new themes, customize core so it includes the features his site needed but not the ones other sites do, make it so easy that everyone will use it, and make sure that the influx of new users gets more support than the current crop does.
Check.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
Yeah sure
I agree with most of what you said there. Nevertheless he made some good points FOR Drupal that everyone seems to ignore.
Also lets not forget that he did not post this here, but someone else did without asking him.
Maybe it was taken out of context (I didn't check his website) and maybe he only wrote this specifically for his needs. Maybe the citation was taken out of context. Did you bother to check his website?
I think rather than thrashing around, we should waste our time helping others instead of wasting our time criticizing others.
What about a seemingly simple question I had and haven't been able to find a solution with Drupal:
http://drupal.org/node/54042
Most of the time when I post one feature request or asking for someones opinion on how to approach a certain issue I don't get an answer.
Many of my posts remain unanswered.
How if each of us abandons this really meaningful thread and takes a couple of minutes to answer two questions. That would really make a difference.
Andre
The best way to learn Drupal
Hi André
I mostly agree with you. Sure there are some questions who are left without responses...I 've experienced this fact by myself too... But there was also a few people who helped me.
I think actually, that for mastering Drupal a little bit you have to know a certain amount of PHP coding. For exemple I'm a designer and to understand the phptemplate, this is the only way... That why I disagree with people like Mr Dries who don't unsterstand how hard it's for us - non programmer - to master some Drupal features. He is a PHP developper and then it's so easy to resolve by himself a problem or understand Drupal programming behaviour. So Mr Dries is wrong : sorry newbies questions are not always related to personal problem but can be related general feedback. They can also express a common feeling, as some questions seems to come back often in the forum.
I know on the other way how some newbies questions can be painfull towards programmer. After all we have a very very good CMS (and more) for peanuts. Does it mean that the base must says nothing ?? Certainly not. Users are not always idiots, they have very pragmatic question too. Nobody want to see Drupal as a tool for programmer only. And critics can be constructive.
I've study a lot of CMS and my conclusion is that Drupal is one of the best, so many thanks to the creators. But Drupal needs some efforts in terms of learning. If people are looking for a easy CMS they can look at Mambo/Joomla or SPIP... If you are interested by Drupal, it's means, IMO, that you have more professionnal needs. So it imply a greater learning curve. But it remains simplier and less ressouces hungry than for exemple Typo 3. I like the taxonomy and flexinode concept, and the community features... When I see module like cck or Ajax implementation, the futur of Drupal seems so bright.
The best advice that I can give when you want a broad view on Drupal is to buy the only book wrote about Drupal by Robert Douglass. It's mostly about version 4.7 sure, but it's a very good written book. It avoid you the pain to search among a lot of online documentation. This is the major problem...you have online all the responses, but they are disseminated in a fragmented way.
The final question is : can we have a easy Drupal (for users and designers) and a very powerfull Drupal (for programmer) ? ... .
For succeding that, in the future one of the greatest needs will be interface and usability team for Drupal.
P.S. sorry for my english, it's not my native langage.. so beside Drupal I have to master english too...;-)
Make A Difference
If you want to make changes to Drupal this page is a must read....
HOWTO: Enact change within the Drupal community
http://drupal.org/node/36602
As an open source product, it's possible for anyone to start making changes to it - you just need to go about it the right way.
Cortext Communications
Drupal Themes & Modules
------------------------------------------
Drupal Specialists: Consulting, Development & Training
Robert Castelo, CTO
Code Positive
London, United Kingdom
----
Want to point out one thing...
One thing I want to make sure and point out to everyone who's feeling that Drupal is too hard to use, there is active development going on right now to create an installer for Drupal (one of the main complaints we tend to hear from new users) and we need your help (yes, you! the newbie!).
There are two areas where you could really pitch in and lend a hand:
1. We need people to test the installer. Jeremy's made it really easy by providing copies of Drupal 4.7 to download that already have the patches installed! You just unzip it like you do any normal version of Drupal and away you go!
2. If the above sounds too scary/time-consuming/whatever, we also need help writing nice, friendly error messages so that people just like you are able to install Drupal easily and with no fuss, no muss!
These are two example areas where we actually *really need* a new user's perspective. So please choose to actually take action on some of the criticism levied here and elsewhere, rather than merely stating opinions about how other people should take action. ;)
Point by point (sort of)
The documentation looks much better than it did with my first attempt at Drupal just before the 4.6 release. It could have more cross-references, less nesting, and some areas could be improved by those with the expertise, but if you take the time, there is a lot there to appreciate.
Most modules Just Work™. Those in CVS or designed for 4.6 and working their way to 4.7 require more work. You can usually find the problems in the Issues or CVS Messages before installing, but if you don't, submit them yourself.
The search works great half the time, poorly the other half. But that's comparing it to Google, a company that spends millions (billions?) on improving their search results and has more search algorithms than Drupal ever will. Page Rank™ and other complex features will never be feasible for a site running on a single server.
That one's easy. For the latter, copy the node.tpl.php from bluemarine to your theme and make a couple of one-line html changes. Views allow the rest, but I haven't learned it well enough to describe it yet, having just installed it a couple days ago.
I mention it in many of my posts, but Category.module is the way to go for this, in my opinion. It automatically sets up the hierarchical menus if that's what you wanted, and can be setup to display pages that show the whole hierarchy and allow you to drill down, even displaying associated nodes on each level. It's basically the module that got me back into Drupal with it's powerful features.
This I find hard to believe. The module is very new and doesn't have thorough documentation yet. But if you're that determined to use it, you'd just install it like any other module and play with the boxes on the form in its settings until you understood what it was capable of. Then read the few sections of the handbook on it and realize you can put your Views in snippets and then go "Aha! Now I get it! Its really powerful."
Some of that I can see. Your default installation may make you wonder what you're supposed to do with it, at least if you have a site in mind that is more complex than a blog, and have clear goals of maintainability in mind. That's what happens to people at the level of programmer or site designer with preset expectations, but who don't have enough expertise in PHP or drupal coding specifically to make it meet those expectations. You have to dig in, or you have to live with what others have given you for free. Much of it is very well designed anyway.
That was the funniest line in the whole thing. You know what you're getting with open source interpreted languages just by reading the code, if you're "an object-oriented programmer of 6 years." You should be less secure in the idea of running someone else's compiled code.
-- Ben // profilefx.com
Pretty much.
The post seemed like an odd mix of true observations, misunderstandings, and downright baffling opinions about software development in general, rather than Drupal in particular. This post seems to demonstrate that the author didn't take the time to figure out "the Drupal Way" to do certain things, and instead just hacked core willy-nilly. Given that approach, it's no wonder he is worried about upgrading to future versions.
But, as another poster said, it's probably better to abandon the thread and help out folks with questions. This seemed more like a drive-by Op-Edding. Weird that he set up a new blog specifically for this post.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
LOL
I could not stop laughing reading some comments guys. I did not want to post any reply because I said my point in the blog, but few thing deserves to be specified.
Why you assum that I have no I dea about open source spirit and open source development?
If for you open source means write some crappy code droped somwhere in a cvs repository and hope that somebody is going to used and pay you for fixing the bugs, then I probably have a wrong vision oabout open source.
The documentation is horrible. Despite whatever you said. Maybe for a drupal commiter is good enough but for a user is useless. As I said in my post the forum was much useful.
Nice to meet you sepeck, I really like people that put alot of passion in their thoughts but as I don't expect that some open source guy so solve my problems for free, you should not also expect some guy which is doing a website for fun to start solving your bugs in drupal. The point that you are missing is that is a big difference between people who pays there bills by providing drupal solutions
(I bet you are one of those) and the people who just experinece drupal. If I will get money using drupal then probably I would have some time to fix some issues in this project. I was just a poor guy trying to setup a soccer portal in the fastest way possible and I still think drupal was the fastest way.
Someone blast me for trying directory.module(hasn't been release yet he said) and other balst me because I didn't like to use modules directly from cvs.... An other recommend me another unreleased module(category) which is for drupal 4.7... .. That is funny..
Some on said that you don't need testing and other made assumption about how I install drupal. Wake up guys! Download latest drupal distribution and start adding modules to it. Check how many modules will be added whitout pain. In my experience even the trivial image module had to be changed and almost all the others. For example I could not make the ping module to work in any way. I had to make a ruby script to ping pingomatig an run it by a cron job. The years for the archive view had been hard coded in script source. This means now every year I have to remmber to chage that script. This is not a case of open source but simple bad developer "contributing" to an open source project. I believe Not testing your code really makes you a bad developer.
You blame me that I kept my fixes for my self. Is not true. Most of the fixes I took from the forums, I did not keep any secret. However if you thing that my contribution (a guy who never used Php before) is so valuable I give you the enitre sources for my site.
Everybody would love to see me contributing, but noone realize that my blog was trying to be a contribution to drupal...
Few realized that the blog was not about me but about drupal.
Don't be hypocrites guys. As I don't expect to get unapid support from drupal community, no drupal developer should expect that somebody else is going to fix his own bugs, and he will keep the glory of an open source genius. Also if you don't differentiate between people that are making money from open source (I really appreciate them) and people which try open source products in their spare time I thing you have a problem
One final question. Now if let's say you want to sell a drupal solution to some manager in some company and the guy read this forum thread, do you thing is he going to buy your solution?
Best Regards,
If you are a fan soccer come to my Druapl portal where we try to build a new kind of soccer fan community.
Romulus
You would lose your bet. I
You would lose your bet. I have a day job which has no involvement with using Drupal or designing websites. I make no money from Drupal in any way shape or form.
Your dislikes were useless in that they were flat statements. They contained no 'why', no alternatives and several misunderstandings. It's easy easy to make all encompassing dismissive statements like 'handbook should be deleted'. Without explanation those statements are useless and completely lack context. (did that help?)
Here's your shovel.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Still don't know php....
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
If you think we'd be waiting
If you think we'd be waiting for others to fix our bugs, you are quite wrong. We are able and willing to do that ourselves and even do it on occassion. What we will not do is to fix _your_ bugs, ie bugs in Drupal that you've found and consider important. Sure, we might do that if we find that your bug also bugs us, but if we don't then we won't.
WRT managers reading this thread: they are welcome. Also, I don't sell "solutions" but I offer services to provide solutions. Quite a difference.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
One final question. Now if
Why would anyone considering hiring a consultant to put in Drupal give a damn about the complaints you've had? I think you are attributing more importance to your opinion of the software than is merited. I have been and am in the position to purchase drupal solutions and I can clearly see this thread is high on the sour grapes factor and low on the legit complaints factor and I'd probably tune it out. I think that'd be pretty obvious to anyone who read it.
There are some things that it seems you haven't fully grasped. The most complete and tested portion of the product is called core, in other words what you installed initially. That is drupal and the current release (which is 4.6 by the way) is usually fairly bug free. However if people do find bugs they report them and unlike commercial software products, many of them actually get fixed.
Many of your complaints center around the "contributed" modules that do other things. Blaming Drupal itself for these is like trying to blame Microsoft because some application written by a random developer and posted on the web doesn't work - go ahead and submit it to their support and see how hard they laugh at you. Often these modules are not designed to be a complete solution for everyone. Someone was working on a module because they had an interest or perhaps a client needed it or perhaps they just wanted it to work a certain way on their site. In the spirit of open source they've allowed the rest of us to download and use those modules and improve on them. But to get all indignant when one of these contributed modules doesn't work exactly the way you want it to on your site is complete crap.
You very well may have valid complaints about a piece of code or a whole module but the right thing to do is lay this out in a constructive manner instead of the way you've done it. The reason should be pretty obvious, everyone is going to ignore what you said and you won't be able to inspire any sort of change (i.e see this thread). Maybe you don't care but on the off chance you do it would be advisable to think about this next time.
============================================
BuyBlue.org
Same again and again
I understand both views, the one of the user who made his comments, the one of the coders who are (at least partly) upset.
What I wonder is, that some points are posted again and again and again, but somehow no improvement is done. I mean here mainly how the forum is organized and how the search function works, because these are in my opinion the 2 main sources which cause frustration and prevent the community to go forward in a structured way also visible to users just using this CMS and not coding.
1. Forum Organisation
Some topics are discussed widely, often and in many different threads. It is a nightmare to collect such information and even developers of some modules the discussion is about, do not know what all is going on. For example see the discussions about node-to-node relations. Other "hot" topis are for example user rights, mailing, display of nodes.
If there would be Sub-Forums for such widely discussed topics where a) a list of modules dealing with this topic including future plans of these modules as well the drupal core is published b) a discussion about future potential new functions and c) discussion/feedback of the current modules, then all would be nicely in one place and helpful for all.
The fact that in the Post-Installation Forum now 12790 posts exists says all.
2. Search Function
No doubt, the search function is bad. A good search function would help a lot and I think the point about documentation would disappear. Especially in an open source development where information is distributed a good search function is a must to make work more productive and frustration less.
I proposed the split-up into sub-forums before. My question: To whom I have this wish to address to, so it could be discussed? Or are there some reasons that such a new structuring does not make sense?
André
Quick partial answer
Search has been addressed in Drupal 4.7 (drupal.org will upgrade soon); only time will tell if it has improved enough.
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.
nice
that's nice to hear :-).
Improvements happen every month
You mention 'even the developers do not know what is all going on'. This one sentence seems to assume that there is a central coordination amoung the development entity that is Drupal. There isn't. However most people actually doing the work are aware of what is going on in areas of their interest.
Coordination relies on people joining in and discussing. Also, several individuals refuse to coordinate their stuff with others and there is not much anyone can do about that. Much transistory discussions happen on the development maillist as well, so if you really want to follow the higher level development, then reading dev list traffic is the way to go.
Mail handling has recieived a lot of attention and there was even work done. But well, it seems that more work needs to be done and the folks working on it have only so much time in the day so right now mail handling ran out of time and will be revisted in 4.8.
Adding more forums for this years topical discussions will not necessarily help. There have been many people who demand that each contrib module have it's own forum. That would give us an additional 200-400 forums depending. How to determine 'what' subects are of such long term standing interest/benefit that they get there own forums? That's hard but I'm not really the one you have to convince. Dries is also on holiday for a month so it definitly wouldn't happen anyway until he gets back.
As to search, I strongly suggest, as has been repeated many many times, that people help eliminate the few remaining critical bugs so that Drupal.org can upgrade to 4.7 code base. People keep talking about 'oh search is bad' blah blah blah. A solution exists. It requires people stop working on their little side projects and start working on Drupal core. (see http://scratch.drupal.org/search for the future that has been repeatly mentioned)
This is not a secret. This has been announced inthe dev list, I and others have mentioned this in a lot of forum posts including those on the front page. But we don't get anyone new participating in work.
Your ideas sound like you want to see the equivilent of kerneltrap for Drupal. It's been discussed before. It would be great but lacks someone with the interest and time to actually do the work each week.
-Steven Peck
---------
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
why not try it with forums
Thanks for your detailed answer.
I think one major point is the forum. Why can some "hot" topics not be organized in separate forums? There will not be 200-400 forums, there will be maybe 10 such "hot" topics forums. Yes, the question is, who defines what topic deserves to have his own forum. I would say that this is done by one of the administrators. Sure, not every user will have the same opinion about the 10 hot topics, but it is definetely better than having none. Why should we discard an idea because we think it cannot be 100% perfect realized? In my opinion having some "hot" topics forums is much better than none.
And this would help a lot for the publishing of information. As in every organization and company information is a key (and often neglected). I open now in a new posting my proposition, because it has only partly to do with the topic in this thread
Forum organization
Or, you could bundle groups of related modules/functions into forums, eg,
- image upload/processing
- RSS issues
- WYSIWIG editors
- ecommerce/income
- content categorization/tagging
etc.
At least then people have an idea of what area is likely to get the best responses from people working on the same problem as they are.
Our general interest community is based entirely around forums and it really helps people to know that they're in the right spot to discuss *specifically* what interests them. They also know that when they post, they're likely to get responses from people who at least have some knowledge or interest in their particular subject.
Phoebe
--
Visit The Town
meet ~ discuss ~ connect
www.the-town.org
exactly...
exactly this is what I mean. It would help a lot
Wow! Scratch Rocks!
I read drupal.org constantly, and it takes a somewhat-antagonistic thread like this to learn about scratch.drupal.org. This should definitely be linked off the front page ("Curious about 4.7, come see here..."). It may not have the most recent content (weekly refreshes would be good), but it seems to have the bulk of the main site's content, and definitely gives a feel for how things will/should be... And some interesting comparison points between 4.6 and 4.7.
Anyway, nice to see one thing on my wishlist is already done... But I get the feeling like I'd have to join the dev mailing list to have found out about it otherwise... But, maybe not. I'll go do a search on scratch, and see if it's listed somewhere else in the docs. ;)
On the modules issue - I really don't see a huge need to change to forum-per-module... But definitely agree with what's been said about making the bug/issue/feature queues a little more obvious... And, of course, some* kind of download/popularity/stability stats/votes/feelings that are obvious would be nice, as well as the simplest bit (in my mind) - a way to order the modules by recency of activity. That alone would cause the most actively developed modules to rise to the top. Which would be a good thing!
Join the infrastructure list
Join the infrastructure list if you are interested in the goings on and want to help out or the development list to follow the future. Work in progress is posted there.
-Steven Peck
---------
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
Ships passing in the night...
It would definitely be nice if the lists themselves were searchable straight from drupal.org - the mailman site is very clunky, and there isn't even a hint when performing a search that the lists might be a good place to look ("can't find what you're looking for? Try searching our list archives HERE")
I think that (and the nice 4.7 search) would go a long way towards making the Drupal.org site much more DIY from the end-user/non-programmer perspective. The nice bit about forums, issues, etc are that they do turn up in searches (though right now, not in any particular order of relevance)... If the lists did the same, there would finally be a single point of entry into all the latest Drupal news, without having to browse forums, or join 1-8 mailing lists.
You mean this section:
You mean this section: http://drupal.org/node/45471
and this section: http://drupal.org/node/39282
visible from this page: http://drupal.org/handbooks or something else?
Patches welcome. and yes that is a standard answer but frankly your wish requires someones work and it might as well be you doing the work as you concieved of the need. :)
As to the answer of you can't code, well, file it as a 'feature request' against the Drupal project and perhaps someone will take it up. Your idea will get lost in the forums.
Now before you say we should tell people about this... click on the blue Support tab on the top of the site. Then on the right hand site in big H2 fonts is words
feature requests
and a link to where to review them and where to file them.
-Steven Peck
---------
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
My two cents and more
Speaking as someone who is reasonably new to the Drupal community, and who has successfully ported on site to Drupal and is currently finishing development of a second new site on Drupal, I wanted to toss in a few comments.
1. Someone here had an interesting point about the name of the software. I understand why it's called that and so on, but it's true it doesn't have quite the same ring as Ruby on Rails or Firefox or even Mambo. (Note that all of these names have positive, speedy, even sparkling connotations to them. Precious stones, clever fast foxes, fun dances... Drupal? Well, droopy comes to mind... sorry Dries!) Am I right in thinking that Drupal has been around longer than Ruby? Ruby already has more buzz... perhaps a name change would help attract more users and thus also more contributors. It's a non-trivial issue; even in open source, branding is important.
2. I disagree with zero-zero completely about web designers should be told to stay away from Drupal. I know absolutely ZERO php, and with just a little initial help from someone on how to set up a database, I've been able to do just fine.
3. It's been said before, but it bears saying again, Drupal needs more and easier for the newbie to customize themes/skins. If the community can ever knock this one on the head, I think Drupal adoption will be fast and furious.
4. To call the documentation useless is vastly overstating the case. I have however, found the handbook frustrating to use in terms of what it doesn't document and in terms of what it assumes the reader already knows. The fact that some pages have comments on them which contradict each other and the page contents is confusing. Many people have complained about the lack of information about the taxonomy feature, and I suspect many users are missing out on some of the most powerful aspects of drupal simply because they didn't know it COULD do X, Y or Z.
I realize that this is a product of open source, in that everyone contributes what documentation when and where they can - that's fine.
But what I would suggest is that the handbook needs firmer editorial control.
I would like to propose a completely new, far more detailed outline/table of contents, written as though it was meant to be a Drupal textbook, and written by a relative newbie so that it has half a chance of addressing all the things that someone new to Drupal is going to want to know. We can even have something of a template for certain sections so that there is consistency across pages in terms of what information is presented, ie., modules (What is this module for? What does it do? Where are some working examples? etc)
Pages within this TOC/outline could then be filled by the experts, dev people, contributors who know the topic best, and updated by them as well.
Comments/debates about the contents of particular pages should be made in a Drupal Textbook Talk forum, and then when they are resolved, the appropriate changes made by the original page author or whomever has taken over from that author. This would be so that new users aren't immediately confronted with debates about where variable $confusion is REALLY passed when all they're trying to do is find out how to make their slogan show up on the site or something.
I'll shut up now, but for the record, yes, I would be willing to create such a TOC/outline for a new and improved Drupal Textbook.
----
http://www.whatdoesthatmean.com
http://www.ponderfodder.com
http://www.scribendi.com
documentation reorganization suggestions
Your proposal sounds good in theory, but not very practical, IMHO. There has been a ton of new documentation written within the last year. Introducing additional coordination issues and making the process more involved will not solve the root of the problem: there is simply more documentation that needs to be created and edited than there are people to do it.
Besides, I'm not sure where you would recruit all of the additional people to implement the process you are describing. My sense is that those who are wanting to do documentation are already doing it. If even a fraction of those people who complain about taxonomy information would go back and write some documentation up after they figure something out, we'd have better documentation. It is invariably the case that a lot of people want good documentation, but very, very few are willing to write it. Lots of people complain about the difficulty of finding the solution they need in the forums, but very few go back and write that solution up in the handbook.
So what Drupal mainly needs are users that see that the only way for documentation to improve is for everyone to spend time writing it. We need a shift in attitude from "Drupal's documentation is bad" to "Geez, here's something I can write up." If everyone gave their tithe to documentation writing and revising, there'd be no documentation problem :)
I disagree
So what Drupal mainly needs are users that see that the only way for documentation to improve is for everyone to spend time writing it.
Sounds great... except that people like me can't write what we don't know about. I still don't know all the ways to put together an URL to call up vocabulary or terms in specific ways. I suspect there are at least 20 features in Drupal that exist that I don't know about. That type of documentation has to be left to the people who actually build the modules.
The problem is that developers are a bit too close to the product and thus they don't know what *we*, the end users, don't know about. That's why a structured TOC would help clarify what they need to write.
----
http://www.whatdoesthatmean.com
http://www.ponderfodder.com
http://www.scribendi.com
Chicken/egg
Not necessarily. If the 'developers' don't know what others don't know... And the 'others' don't know what they don't know... the Table of Contents would really just devolve into a 'list of unanswered FAQs.'
I'm not saying that there isn't need for improvement, just trying to figure out what the best approach is. Pure task-focused tutorials on How To Do X? High-level explanations of how Drupal renders pages, builds menu, and so on? Detailed explanations of every setting and configuration option? Again, I'm not trying to say that things are great, just puzzling at the best option. I contribute pages here and there when I can, but it's delieriously hard to know exactly what 'users' need when every user's needs look different.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
Not necessarily. If the
Not necessarily. If the 'developers' don't know what others don't know... And the 'others' don't know what they don't know... the Table of Contents would really just devolve into a 'list of unanswered FAQs.'
Huh? I don't see how it would do that. I've already said that someone like myself could come up with a TOC that would draw out the bulk of the required information. What it doesn't, a Textbook Talk forum would help fill out fairly quickly.
Look, this isn't rocket science... and yes, while each user is going to want a slightly different configuration than another user, there are key questions that I see coming up over and over again in the forums. Clearly there's a core set of things that aren't being covered well in the handbook.
----
http://www.whatdoesthatmean.com
http://www.ponderfodder.com
http://www.scribendi.com
Can you?
I don't mean that in a sarcastic way. If you could compile a list of those frequent questions and consolidate them, it would be a great help. 99% of the FAQs that I see are answered in the handbook, but they are located in a section that's not intuitive to someone just tinkering around with Drupal.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
Yes
I think it would be possible to establish just such an FAQ. Here's how:
1. First create a page where people submit there questions.
2. Aggregate those questions (through votes, number of times submitted, whatever)
3. Establish a page where those question are seen by the most people.
4. Allow other users to answer the questions (through links to existing nodes, copy and pasting solutions from elsewhere, or answering it outright.)
5. Archive answered questions in an indexable easy to search manner.
Possible existing interfaces to emulate:
1. answers.google.com
2. wikipedia.com
3. digg.com
Or we could ajaxify our own solution.
Okay, problem #2
You've just suggested a rather complex software-based solution to a problem you said anyone familiar with Drupal's forums could do themselves.
All developer hands are, right now, focused on getting 4.7 cleaned up, and getting must-have modules like project and cvs updated so that drupal.org can start running on 4.7. Coding the solution above just for a FAQ page is probably not going to happen, at least in the short term. Is there any way that you (or someone else reading this thread?) would be willing to compile a first-pass list of the questions that are frequently asked here on the Drupal forums? It really, seriously would help.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
list
jeff, the list of most frequently viewed handbook pages is such a list
I did?
I did? I know the solution is complex but I didn't mean to imply that anyone familiar with Drupal's forum could do this themselves.
I do not frequent the forums enough to allege that I am knowledible about what questions are asked most frequently. I am suggesting that in order to determine what questions are most frequently asked we need to have a way to organically organize the frequently asked questions and their answers.
I would be happy to attempt to create something that meets the design goals above. But I think the work is already done.
it could be done with the following modules:
1. Flexinode
2. Medium Vote
3. Views
4. taxonomy
1. The flexinode module could create a node with a title (textbox), a question (textarea), and an answer (textarea).
2. Medium vote extends nodes to allow the nodes to be voted on. We could create a new node named FAQ and extend the voting capability on it.
3. Then you could use the Views module to sort posts of that specific node type by the number of votes. You could also configure the view so that when the post has been answered to the satisfaction of the user the faq request is closed and therefore archived
4. With the taxonomy module posts could be categoried and therefore sorted within a tree-based and/or flat heirarchy.
If I or someone else clever enough we could implement this idea in a digg.com-like fashion.
OR
2. you could allow the comments to be the answers and then apply voting on the comments to rank the answers. (just brainstorming here)
Write what you do know
The trick is for people to write what they do know as they figure things out. It's that simple.
The problem *is not* that developers are a bit too close to the product. Developers are doing what they need to spend most of their time doing -- develop. And those of use who don't develop should be doing the documentation writing.
I can say this because I don't code. I've managed to figure out things that were not documented, and in some instances, have written documentation for it.
A note...
I've found that developers are almost always willing to help a documentation writer understand something -- even if said developre isn't able to write user-friendly documentation to save their lives. ;-)
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
+1
Definitely. People are always willing to explain something so that documentation can be written.
I don't think we will change
I don't think we will change the name. The suggestion has some merit, however it is also based on a quite common misconception: That we would be interested in growing our "market share" etc. This is not the case.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Although...
I think it does hold promise for Drupal-based distributions. CivicSpace, for example, is nice and catchy. :-)
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
What's in a name?
For all I know, Drupal sounds real catchy in Dutch. For the record, when I mentioned the name, I wasn't advocating for a change, but rather just making an observation about my personal thoughts on the matter.
Like Jeff mentioned, solution providers are going to use whatever name suits them, even if Drupal is the core software they are using to provide services to clients. Therefore, what it's called isn't really an issue.
Roger
Also for the record...
... My 2006 to-do list is getting crowded with ideas for market-targeted Drupal distributions that would carry their own catchy names. I really wish I had an army of minions to do my bidding. Heh.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
Linux and Tux
Linux was a pretty screwy name when I first encountered it. Then there is the damn penguin mascot :)
Besides...Drupal, Plone, Joomla, Moodle--we are in good company.
If I were starting distribution, I'd probably go for something strange too . . . . like what in the world is an "iPod?" ;)
iPod
That one actually makes sense to me.
iMac, iTunes, iPod, iphoto ...
iTunes is where you get the Tunes
iPod is where you put them (Pod)
iMac is where you download them
i-nternet is the download medium
iphoto and idvd are self explainatory
I am waiting for:
iflix (movies)
irings (ring tones)
ibooks (ebooks for mac users)
....
-------------------------------------------------
http://www.opentravelinfo.com
http://www.aguntherphotography.com
Drupal is great
Hi guys, My last comment I promise :)
First of all, I said few times that drupal did his job in short time, and I never said that I hate drupal or I am not going to use it again.
Second: my complaints about contributed modules were about some moduels which I beleive are used by alomost everyone like image or organic groups.
However I had also to fix modules from the core distributons, so please don't be ignorant about some problems there, and also not exclude by default(as I read in a comment) the value of some written tests.
Third: I am sorry that I upset some guys which (as I understood) worked hard on documentation, but I have to repeat Excluding the installation, I wasn't able to resolve any of my problem browsing documetnation. Ok , I was to harsh in saying the must be deleted but I guess(regarding how many comments about documentation have been on the thread) everybody got the point. Also, I can tell you for sure that all major open source java projects had by far a better documentation.
And Last:
If I wouldn't said anything or I would only say the great things about drupal(remeber? my post has a section called The Good) probably my post will be useless. So despite your anger I am happy wiht my "contribution" to drupal.
P.S.
Steven Peck - I own you a beer and besides the bet, I have all the respect in the world for a guy who in his spare time take cares of the documentation for an open source project.
Loking forward for a better Drupal,
Romulus
Please don't
Please don't assume that everyone needs organic groups. I don't have a need for them.
One reason I like Drupal is that the core is rather small and not too much inflated.
Andre
http://www.aguntherphotography.com
http://www.opentravelinfo.com
My thoughts, for what they’re worth.
Now that we've seen this issue has simmered down, I'd like to offer my thoughts about what I perceive to be an organization problem. I promise not to talk about searching, since that issue has already been discussed sufficiently (for those just tuning in: yes search sucks on the current drupal.org site, yes there is a solution ready once it moves to drupal 4.7). First, a preamble:
I think that the organization issues can be solved with current drupal technology and that as developers it is role to diagnose problems and suggest solutions. I will outline three changes that will improve the job of technical support, documentation, and communication that the drupal.org site is for.
1. Documentation Wikies.
Our drupal.org site currently has an open commenting system for all books, forum posts, articles, etc etc. What I propose is that we establish a wiki to house all documentation so that when modifications (that today come in the forum of comments) are consolidated back into the posted article. Wikies could provide for user managed FAQ’s, support documentation, and snippets. The main point here is that with so much documentation out there, the best (and perhaps only) way to efficiently organize them all is let the users categorize and sort all the information for you.
Wikies also provide a way to apply a free tagging based organization of information.
The tagging could cross reference books, support requests, Which leads me to my next suggestion
2. Apply Freetagging organization to all forum posts.
We have discussed the creation of additional forums to facilitate better forum post organization. While I agree that the creation of more forums for modules is a good idea, I also see the benefit of allowing drupal’s users to create forum topic categories on the fly.
I am using drupal 4.7 with freetagging taxonomies on the site I run for my friends. They do tend to create new categories every time they create a new post. But I think that if we allowed drupal users the ability to dymanically create the categories we will find that posts tend to share the same categories.
To prevent a spamming of new categories, you could only extend the right of creating new categories to a trusted few. If DB bloat is still a concern, we could always switch the forum categories from a freeflow textbox to a drop down or select box and allow users to select the proper categories for their post.
The categories could sync with the wiki and the new better search function to cross-reference posts.
3. Establish a sourceforge-like webapp for module and site code development.
Its is hard to admit that the current established way of doing things isn’t sufficient for its job. Harder still when you’ve invested so much time and effort into the project. But I think it is time to look at the current manner of listing projects and the resources module maintainers are given. I would like to see a full sourceforge like webapp provided to developers, but know from experience how difficult it is to set one of those up.
Someone said that we would have to create like 200-400 new forums if we intend to provide a new forum for each module. I say that’s exactly what we need, a forum per module. Any other solution would necessitate the grouping of forum posts in a many-to-one relationship that forces a user seeking an answer to a problem with a specific module to discern what posts within a forum relate to the module they are having a problem with and which do not.
Sourceforge provides an established webspace for each project with forums, CVS, bug tracking, you name it. If a user is used to the process of finding the project they’re looking for, then goto its forum, then post their question, they would be right at home. Today they navigate through downloads to get to the project they want. Eventually wind up in the support forum and decide whether they want to post their question about a specific module (or anthing) from one of ten forums. An experience user would know to post a new bug report (which really could be support request or feature request too), since the module’s author would eventually read the post. This is what I’ve learned from watching the recent posts section.
So what I'm suggesting here is that we revamp the project module to module after sourceforge. Perhaps we don't need everything it offers, but I think that project.module needs to provide more.
So to sum up:
The frustrations that many have (experience and new users alike) can all be solved by a thoughtful application of available technology. Thank you for making such a good product. I hope to help make it better.
Edit: Fixed many grammatical errors for readibility.
I wasn't upset, I was trying to educate
I really thought it was funny. Statements without explanation arn't useful, can't be discussed and lead to no where. :)
There's handbook work continuing on from my January post.
Wiki's suck for organizing large volumes of information. Developers always talk wiki's but (yes I know about wikipedia) but wiki's suck for organization and long term structure. A support group where I work is using wiki's and now that the have 100 pages they can't find anything without a dozen clicks and the growing frustration is causing duplication of content and managment issue's with existing content. We have significantly more than 100 pages inthe handbook and after the last re-org I have seen people hitting pages and reading them and certain types of forum questions have dropped. Still needs more work.
Revisions behavior has vastly improved for 4.7 so wiki like behavior is posible but we plan on waiting to experiment with it until 4.7 is actully released and we have more discussion. Right now the focus is on 4.7 release (stay on target). See the documentation list archives and feel free to join the docs list and re-raise it. We will need to experiment with what 4.7 revisions and moderation will give us and how the behavior will actually work so that we can effectively manage it and before we just open it up. Moderation has some interesting results sometimes.
The phrase 'docs need work' is meaningless. Big shock to me. I know of specific areas where the docs need work. We have people working on them. I think that's about 7 people. The dev handbook hasn't been re-orged yet, still exploring what to do. Customizationand theming had a plan, then someone dumped a bunch of content in a difficult place for me, so I am having to revisit the plan for that book. (I'd rather have the content so will live with replanning). But if people feel that certain areas are more important then others, feel free to be specific, general statements are like the wind.
I'd rather that some newcomer docs that people that publically chastize us' all the time for not having show up. I'd like to see these people actually produce these so called mythical newcomer docs they promised so that we can add to the handbook. (this is not directed at you, merely bringing up that many have promised in the forums and still not produced months later so I am wary of yet another suggestion to change things again before we're done with the current evolution. I'd rather finish the strucutre first.
So far still waiting for new comer docs. Started some misc stuff in my spare time http://www.blkmtn.org/book/drupal that I will add once I have the settings section written up. Not my highest priortiy at the moment with work load and misc other projects on going.
Forums per module will not happen for several reasons. Scalability. There is no point. If you post questions about a module in the one single specialty forum then the person who could have given you a better solution will never see it because he thinks that module frankly sucks and doesn't scale well and never looks in that one special forum. :) It would be better to suggest broad categories for forums for differing target sites. Think of a Drupal site in a holistic sense, not an indivdiual module sense. Module combinations to generate solutions, not individual components (I hope that explains the concept well)
The current manner of listing projects? Hmmm..... http://scratch.drupal.org/project/Modules < see, neat hunh? If only people would help fix 4.7 stuff we could upgrade Drupal.org and have that. Every project on drupal.org already has an issue tracker.
As to revamping the project module... heh heh... Someone had to pay for it as no volunteer bothered to step forward. Long list of discussions in the development archives.
Welcome to the community, hop on, pick up a shovel and let's get to work. Sign up to the mail lists of area's that you are interested in, scan the archives to catch up and look forward to having fun. It's a diverse community that does get things done in an evolutionary fashion over time by the people who do work. It's been an insane time for me.
-Steven Peck
---------
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
Room for debate
thank you for your well thought out post. I think there is room for debate on the points of how to effectively organize information, view that information, and scalability. I aim to debate you on those points and futher eleborate my ideas on how to improve the drupal.org website.
1. best practices for organization
I see your point on the troubles that wikis create when establishing an organization structure of the site. Wikis are not a magic pill. The proper mapping and planning of the organization tree is still required. My point was that the open modification features and cross-link features make your standard wiki a good candidate for improving the mothersite. If in the next revision of drupal we gain comparable open modification features (I know we will have the ability to do free-tagging) ... and those features are turned on. Then we will have effective enabled wiki-like features for this site and the enthusiasts like myself will be able to hunt down ways to better organize things.
2. Viewing that information : forums
Though you did not claim that the current forum structure is ideal, I am perplexed with your hesitancy of supporting the idea of one forum per module. How is this idea different from a one project listing per project idea. Is it difficult to keep track of bugs for a specific project or group of projects? I claim that it isn't, though the claim is understandibly based on preferences and usage habits.
I claim that it isn't difficult because the mothersite provides tools to aggregate all recent bug posts (in general and for a specific project). We also have a tool that aggregates all recent forum posts in recent posts. Today that link shows all recent posts of all nodes. With the Views module we could have just such a page specifically for forum posts or forum posts of a specific type. We could discriminate between posts in the support group of sites, posts in the modules section, posts in themes, etc.
3. Scalability
When we debate about scalability issues, I will assume that you aren't making the point that the DB that houses drupal's data can not scale to handle the increase of demands my plan would require. Let me know if I assume wrongly.
The remaining problem after a transition of one forum per module is how effectively display so many forums in an easy to use manner. Here are few ideas.
A. Link the module's forum to its project listing: Whenever I'm looking for a project I naturally expect to find a link to place where I can post messages about it. Today, i get a link to the support forum.
B. Modules could have their own page: Don't display all the forums at once. Force users to click on a seperate link to goto the module forums.
C. Categorization of modules: As was suggested before, a grouping of modules would help the user pick out their module from a pack.
I think that an accordian style implementation of this idea would be of further benefit. An effort could be made to cross pollenate the blockbar and forum modules so that the same functionality we enjoy in the blockbar module could be applied to the root level forums.
So there you go. Some thoughts to consider this lovely Wednesday. Before I go, I wish to give my thanks. I don't think I fully appreciate the work you and others on your team have done with the books and other documentation efforts. I hope that one day I will.
One forum per module...
Is unnecessary, redundant, and would not be an effective use of resources.
Instead, use the module's issues tracker and post an issue of type "support request" -- that's what it's there for. More often than not, these will get viewed and addressed by the actual module developers faster than random forum posts since most developers pay much closer attention to their issue queues. Some in fact avoid the forums altogether because of big flame-fests like this one turned into above. ;)
Sounds like most of your concerns would be addressed if the "Support Forum" link on module project pages instead read "Get support help" or something, and pointed to the issue tracker with "all" and "support requests" already pre-selected.
C. is already present on scratch.drupal.org, but won't be brought over to www.drupal.org until 4.7 RC and the various outstanding bugs in modules it uses such as project and cvs are worked out. If you're a developer, please check the devel mailing list archives to see what things you should focus on; if you're not, please check the devel mailing archives to see what things need to be tested. :)
Oooh, I like that.
The bit about pointing to support issues instead of the general forum sounds like a good one.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
Good idea
Yea, that would be great. I was kind of confused why the projects had a support category for bug reports. There is indeed a duplication of roles here. Either we provide a place where support requests are handled in with forums per module or use the support category for the already existing project listing per module.
The goal here is that when a user searches answers to problems they are having they would probably use this algorithm
1. Use search box, when they don't find the answer they are looking for there they will...
2. search for the name of the module or click on support
From there they will need to have clear path to move on to their module. Advanced users of this site no to click on downloads, click on cvs, then click on modules, then click on their module so that they eventually get to the bug listing of support requests for that module. That process could be simplified.
I think it would be best simplified by rewriting the support page to provide quick links (through drop down boxes, or other uncluttered UI) to each module's support requests section.
After you transition support requests out of the forum. What then should you do to the existing support section of the forum? Should it continue to exist?
...or Bad idea
Aren’t bugs closed after a certain amount of time? Therefore, aren't support requests posted to project's bug listing also closed, eventually. This would not be the preferred behavior of the main source of support requests. We would want to archive and index support requests so that others could reference them in the future.
If it is true that support requests may be closed then it is clear that the forum per module model of restructuring support is not redundant.
The remaining point to argue would then be whether or not it would be a waste of resources. But isn’t this point moot? Should we worry about the consumption of hard drive space necessitated by the addition of many more forums? I ask because I do not know about the current servers hosting drupal.org.
No...
Issues are only set to status "closed" after a period of time (I think 2 weeks) after they've been set to status "fixed" which means only resolved ones are closed (or of course those that have been set to "closed" manually). And even then, you can still see old bugs/issues/support requests by changing the filters to show as opposed to just "active". This is what I suggested doing above.
re: "I think it would be best simplified by rewriting the support page to provide quick links (through drop down boxes, or other uncluttered UI) to each module's support requests section."
Please do a some mock-ups of how you envision this looking. It makes it much easier to discuss if there's something concrete to back it up.
"After you transition support requests out of the forum. What then should you do to the existing support section of the forum? Should it continue to exist?"
No! There are TONS of support requests that either fall into Drupal itself, or more general "I want to do x, y, z... what modules should I use?" or even "I have no idea what to do with this problem but here it is." But for ones specifically about a particular module.. "How do I add users to my organic groups?"... those are much better served in the issues queue as a support request, imo.
Please do a some mock-ups of
Agreed. Is there a place I can post pictures of mock-ups on this site? I might have some time to do this tonight.
So the forum survives, but repurposed as a kind of first level technical support section. A place where new users post their questions (and/or frustrations) in place that will be indexed and search by users who advance to the next level of the learning curve. I like it.
Mockup finished
I've finished my mockup of my ideas, but am wondering how I can post it to the drupal.org site in a manner that preserves its formatting. I would like to be able to post a picture of my hand-drawn mockup. Is that possible?
create an issue and attach
create an issue and attach it:
http://drupal.org/node/add/project_issue
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Many users are frustrated by searching information
I am not sure whether the most urgent point is to have forums per module, on the other hand I do also not see why there is a serious problem to realize it, it is just one way of organizing information.
Much more urgent seems to me to organize information by "hot topics" as written before and explained here: http://drupal.org/node/54816
Today it is quite often a nightmare to collect some information about a specific topic. I think searching information about a concrete encountered "problem" is ok the way it is today, but not about basic concepts and principles and basic site configurations. Above I take the example "node relations" in my post. Even after reading posts about this for hours if not a day, I still do not know what modules are today up-to-date and what are the plans (I am working now with tagnodes). This cannot be the goal of our community, right? I found posts of several users discussing in depth what a future module on node relations must be able to do, but, these posts are "hanging" somewhere in the 12'000 post-installation posts around. If there would be hot-topic forum "node-relations", then the discussion and information sharing would be focused. New users can get an overview within short time. Ideas can be collected and discussed efficiently.
About missing new comer docs (sepeck's statement): I am new to drupal and I write now a documentation about building my first site and hope to address questions other new users also have. I hope to have a first version in a few weeks to have it reviewed and to have also some comments of drupal developers on open questions.
André
thanks for the link
It is a good idea to start a new thread since we're tangenting. I'll continue there.
The most current module you
The most current module you should use is the one's branched 4.6. You should be using 4.6 if you are new to Drupal and you should be using 4.6 module series as it is the current stable release.
This is clearly documented here in the entry titled Drupal version numbers or which version you should use. If you are a developer and want to play, then feel free to use the CVS/Beta code releases. As to which modules are up to date to run on them? Well, you have to try them, look through CVS logs.... 4.7 is still beta, do not use it unless you are willing to play development/unstable.
Why would node relationship be a hot topic for me? I mean, it seems to be for you, but it's certainly not for me. :)
It's hard to have 'community hot topics. The 'new forum' topics block used to be active topics but people rose up and demanded it be changed to New topics instead so Dries changed it. You seem to be advocating it be changed back. Now, I don't have a propblem with that myself as I ignored that block both times. I scroll through the http://drupal.org/tracker to find recent and active topics as the tracker alreader essentially does this.
If you mean some sort of 'bookmark' module, the two existing options are not of sufficient quaility to be included on Drupal.org at this time and no one has stepped forward other then to say, ya it'd be neat if someone worked on them.
If you mean search, I am not going to go over people need to work on CVS critical bug fixes so we can get Drupal.org up to the new search engine which will let you do far more selective searches.
I look forward to seeing your docs. Now's the best time as you will be paying attention to the steps you are taking while building your site. When you're ready put them in the site recipes section.
-Steven Peck
---------
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 look forward to seeing
Let me be honest with you. I am not a documentation guy. I rarely even read them and if, I prefer to be able to find what I am looking for quickly. For that matter I use google to search drupal.org (and I have no problem with that)
As for my future contributions:
I am developing multiple sites right now. As time goes by and I get more comfortable with php and css I will contribute some themes and some module (I already have several ideas but not enough time for implementation).
To me, search is only important to my own sites. Personally I know how to find information if I really need it, but many visitors to my site don't. I just have to look at the search queries in my watchdog log.
Now to make one thing clear: I like Drupal. My critizism is meant to be constructive b*tch*ng. I am aware it sometimes sounds worse than I intended.
Andre
-------------------------------------------------
http://www.opentravelinfo.com
http://www.aguntherphotography.com
I took your comments as
I took your comments as constructive so don't worry about it. Any write-ups you do don't necessarily have to be the greatest but if they exist, someone else can come along and update or improve or add to them. It's getting them to initially exist that seems to be the problem. :)
-Steven Peck
---------
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 will see
I will see what I can do. I am not one of the greatest designers / devlopers, so I was always somewhat carefull with writing documentation.
Either way, I will see what comes up.
I can write something about my html cache later.
About testing 4.7. Its a chicken and egg problem. Unless there are plenty of modules available, I simply cannot switch my live sites over. I am doing a new site with 4.7 right now, but sometimes I get a little frustrated about missing modules.
-------------------------------------------------
http://www.opentravelinfo.com
http://www.aguntherphotography.com
sorry, don't understand some thoughts
of your post. Why you write about modules 4.6? This is not the point of my post. Beside this you asked several times other people to do testing with 4.7. So, I am doing it, I am building my site with 4.7 and take the modules I need and test.
About "node relationships" not being a hot topic to you: That's exactly the point, it is not the question whether exactly this topic is hot to you or me, the question is, what is hot to many users. I define "hot" what has many posts or maybe is also a key feature of databases and applications. There are other hot topics.
I don't understand your thoughts about tracker in relation to the propisition of having forums around hot topics. Maybe hot topics is the wrong term? My proposition described in http://drupal.org/node/54816 focuses to another point and I want to repeat that the comments of phoebe in this thread are very good too, he offers his help and he has, as he writes, a lot of experience in this stuff.
For each new piece of information I need I do searches. Compared to Joomla, the number of posts of users expressing frustration is here at drupal by factors higher than at Joomla. Should this not be worth to think about, if we are interested in drupal?
With an organisation of a few hot topics (let's say 10) in separate forums, all users would have fast, newest information and discussions would be focused. It is hard to understand for me that you do not like to improve the organization of the information. What is the problem? Do I overlook something? Is having 12'000 posts in one subforum not something we should think about? Is it not worth to try it? And then review the experience? Do I overlook some high costs (costs in terms of time for example) to do 10 such forums around hot topics as proposed in http://drupal.org/node/54816? Your statement gives the feeling that the way it is today is perfect because it worked the recent years like this, so no need to change and no need for any new propositions. I don't tell that this is your intention, I tell that your post above gives partly this feeling.
I can ensure you, if I would not like drupal a lot, I would not invest time and energy in such propositions.
André
Stop saying I am against
Stop saying I am against something. Stop accusing me of things I DID NOT SAY! It's annoying as hell while I am trying to help you define what you want more clearly.
I'm trying to understand what you are asking for. If you want change you need to 'make your case'. Dries is on vacation so there will be no change before he gets back and he has final say and his immediate focus is 4.7 so if you want a change as dramatic as restructuring the forums, then it needs to be defined and clearly state what benefits you think it will have and why you think so.
So we're trying to help you define what it is you want and what you think it will acomplish. Some ideas proposed so far are not practical (200 forums) and we've given reasons and alternative suggestions in return.
Search will be significantly improved in 4.7. We CAN'T move Drupal.org to the 4.7 code base until the Critical bugs are fixed so frankly talking about search is not interesting until we move to 4.7 code base and get feedback user experiance and we can't move to 4.7 code base until people contribute patches to critical issues and fix them so we can get the better search.
Much forum information is also topical and grows stale within a few months or a year (within a Drupal version cycle). Drupal is a different user market then Joomla and I don't use Joomla so again, not an interesting point for 'me' (maybe for someone else) but it is also not immediatly relavant to me how 'our' revamping the forums organization is tied there.
I also said we used to have an 'active topics' block which I think is what you mean by a 'hot topics' block but since I've not seen a hot topics block I'm not sure. There is a default 'Active forum topics' block that ships with a default Drupal install. People said that they'd rather have a New Forum Topics block to help newcomers and deal with unanswered questions instead so Dries changed it last year. Or do you want a complete new forum that will somehow 'consist' of 'hot topics' all by itself? Do you want both blocks and if so where would they go? The front page, the forums page? etc....
This is a discussion to define what you are asking. I am not inherently against it, nor am I for it but you will need a solid proposal worked out with all the why's and expected benefits before it will happen and I'm trying to help you see the elements you will need to get to a solid proposal.
-Steven Peck
---------
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 can only repeat
that my proposition is not about search (since this is obviously covered in 4.7). Also I speak not about 200 forums. My proposition is written here (as written several times before): http://drupal.org/node/54816
I have written down there my idea, why I think it is good etc. Phoebe added some more ideas and described also why he thinks it is good.
Probably the term "hot topics" is misleading, but reading this other post I hope it should be clear what I mean.
Annoying
It is very annoying to click on the link in this post and find out the page no longer exists!
True, the original link
True, the original link doesn't exist anymore, but the content itself was copied into the second or third message of this thread.
Ludo
...
And a year old.
-Steven Peck
---------
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