Encouraging Collaboration
The 4.7 / Forms API upgrade is going to create a learning curve for many module developers, and some of the less-active module owners may not have the time and inclination to make the switch. That could be good news. A lot of these efforts are "learning experiences" that are not being maintained at all. Some of the authors can't be reached, and if you're too polite to overwrite those modules you start new. Some developers feel that it's more rewarding to have their name in lights than to collaborate on a module that's more useful and stable overall. Some people just don't play well with others. As an alternative to upgrading, some module developers could look at modules with similar functionality and try to help upgrade and enhance those. Do we really need 3 Amazon modules? 6 "mail this thing" modules? (one of these is my fault) Can the Flikr Block module be part of the Flikr Module? The list is endless. This is a big problem for new Drupal users and old timers alike. It's not clear which modules are being maintained and how well they work. A few months ago, I tried all the Amazon modules and discovered that each gave me about 60% of a solution. I finally just dropped the idea if using Amazon at all. I'm sure this sort of thing happens a lot, and we never even hear about it. I'm not saying that any of these modules deserves to die, or that they can't possibly be bringing anything new to the table, but I would offer these suggestions: - As part of the call for upgrades 4.7, recommend that module developers try to combine efforts - Encourage people to maintain TODO lists for modules so that others can understand overall goals and see if added functionality would be useful - Encourage people to archive and retire their abandoned projects from CVS. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
For the record, there will only be two Amazon modules in 4.7...I have Amazon associate tools and Amazon search...the search will be folded entirely into AAT. And back when I first released it, Ber suggested I combine efforts with the author of the othe one. We agreed, but I got zero input so I just wrote what I needed for myself. I think I'm seen as one who doesn't play well with others...I've noticed my comments only get responses when someone thinks they can correct me. You got gatekeepers here like in any other group, and I'm finally going to mention something that annoyed me. Before becoming familiar with the cultural aspects of this group AAT shipped with my associate code as the default. I figured anyone that used it would change it. Lot of objections...we don't want people to think we're hustling them. So fine, i change it...as I said, I didn't feel it would have a significant impact one way or the other. The comment said i changed it because community sentiment ran against it. I got an email complaining that I said it was "mere sentiment." My response was, relax...your project, so your sentiment is enough reason to change it. I'm not the one to whine in a public forum. I offer help when I think I can be of help, I return code to the project that I benefit from. I am offered little beyond the code base. That's just the way it is, I guess. But since the topic came up... On 11/18/05, Allie Micka <allie@pajunas.com> wrote:
The 4.7 / Forms API upgrade is going to create a learning curve for many module developers, and some of the less-active module owners may not have the time and inclination to make the switch. That could be good news.
A lot of these efforts are "learning experiences" that are not being maintained at all. Some of the authors can't be reached, and if you're too polite to overwrite those modules you start new. Some developers feel that it's more rewarding to have their name in lights than to collaborate on a module that's more useful and stable overall. Some people just don't play well with others.
As an alternative to upgrading, some module developers could look at modules with similar functionality and try to help upgrade and enhance those. Do we really need 3 Amazon modules? 6 "mail this thing" modules? (one of these is my fault) Can the Flikr Block module be part of the Flikr Module? The list is endless.
This is a big problem for new Drupal users and old timers alike. It's not clear which modules are being maintained and how well they work. A few months ago, I tried all the Amazon modules and discovered that each gave me about 60% of a solution. I finally just dropped the idea if using Amazon at all. I'm sure this sort of thing happens a lot, and we never even hear about it.
I'm not saying that any of these modules deserves to die, or that they can't possibly be bringing anything new to the table, but I would offer these suggestions:
- As part of the call for upgrades 4.7, recommend that module developers try to combine efforts - Encourage people to maintain TODO lists for modules so that others can understand overall goals and see if added functionality would be useful - Encourage people to archive and retire their abandoned projects from CVS.
Allie Micka pajunas interactive, inc. http://www.pajunas.com
scalable web hosting and open source strategies
On Nov 18, 2005, at 9:46 AM, Earl Dunovant wrote:
For the record, there will only be two Amazon modules in 4.7...I have Amazon associate tools and Amazon search...the search will be folded entirely into AAT. And back when I first released it, Ber suggested I combine efforts with the author of the othe one. We agreed, but I got zero input so I just wrote what I needed for myself.
I'm positive that you aren't the only who has gone this route
I think I'm seen as one who doesn't play well with others...I've noticed my comments only get responses when someone thinks they can correct me. You got gatekeepers here like in any other group, and I'm finally going to mention something that annoyed me. Before becoming familiar with the cultural aspects of this group AAT shipped with my associate code as the default. I figured anyone that used it would change it. Lot of objections...we don't want people to think we're hustling them. So fine, i change it...as I said, I didn't feel it would have a significant impact one way or the other. The comment said i changed it because community sentiment ran against it. I got an email complaining that I said it was "mere sentiment." My response was, relax...your project, so your sentiment is enough reason to change it.
Please understand that I wasn't trying to single any person or project out. I was relating my problem with Amazon because I had it in recent memory, and frankly, because it's on the top of the modules list page. The issue is much broader and I'm sorry if it did not seem that way. But your feedback is important, because it shows the cause/effect of group communications. I know my own reasons for duplicating efforts, and I think it's helpful to hear others' experiences. All communities/projects are implicitly defined by their most vocal members/contributors. We don't have to discuss how to define Drupal's objectives, that definition occurs when core members choose to speak up. For example, I adhere to Drupal's coding standards for my modules. Not because it's a requirement (I think it's just a recommendation). And not just because it's documented someplace. I do it because I have seen other community members chastised for submitting non- conforming core and module code. Since it's being brought up consistently, I've become aware that it's a core value of the Drupal community. I am on a number of technical mailing lists. On some of these lists, it's acceptable to yack about the latest slashdot news, ask for Windows tech support, offer up a room for rent, or send silly pictures of your pets. That rarely happens here. Why? There are OT guidelines on all of these lists, but they are community-enforced. On other lists, it would be acceptable for me to discuss my bellybutton lint as long as my subject line was "OT: My Bellybutton Lint" But if I sent a similarly off-topic post here, I would get responses indicating that I should seek a more appropriate forum. Even if these suggestions were gentle and helpful, I would never ask that type of question here again, and I would send a similar recommendation to the next OT-poster, who would inform the next poster, and so-on. This is why the development list is usually helpful and on-topic (well, except for SCM preferences), even without constant reminders. There are some knee-jerk responses I would change ("code is gold! " "too many checkboxes!" ) but Drupal's culture of professionalism and consistency is the most important reason I use it. Without assigning tasks or defining objectives or creating workflows, I hope we can inject some cultural mojo for duplicate work efforts. But if there ARE tasks and work efforts, I +1 in advance any work towards categorizing and/or reviewing modules, or separating them out by some maturity threshold (code conformance, feature-complete, review ranking, peer review, etc.) My standing policy is to avoid installing any module whose author I don't recognize from this list or irc. That's hardly a system that works for new Drupal users! Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
I didn't feel singled out in any way. It was an opportunity to speak on something that has shaped my participation. Let he who has ears, and all that. On 11/18/05, Allie Micka <allie@pajunas.com> wrote:
Please understand that I wasn't trying to single any person or project out. I was relating my problem with Amazon because I had it in recent memory, and frankly, because it's on the top of the modules list page. The issue is much broader and I'm sorry if it did not seem that way.
On 18-Nov-05, at 7:46 AM, Earl Dunovant wrote:
I think I'm seen as one who doesn't play well with others...I've noticed my comments only get responses when someone thinks they can correct me. You got gatekeepers here like in any other group, and I'm finally going to mention something that annoyed me. Before becoming familiar with the cultural aspects of this group AAT shipped with my associate code as the default. I figured anyone that used it would change it. Lot of objections...we don't want people to think we're hustling them. So fine, i change it...as I said, I didn't feel it would have a significant impact one way or the other. The comment said i changed it because community sentiment ran against it. I got an email complaining that I said it was "mere sentiment." My response was, relax...your project, so your sentiment is enough reason to change it.
Just wanted to say Earl that I've been following your work on your blog with aggregator/paggregator with interest. It's a core module that only sporadically gets attention. I had brought up before that we might consider designated maintainers for core modules -- see http://drupal.org/node/34439 -- there are still the majority that are theoretically "maintained" by Dries. Dries, do you want to speak up and say which ones you *actually* want to maintain, which might be in need of an official maintainer, etc.? I agree with many of Dan's comments, and some of those are "in progress" with upgrades to the project.module being funded by CS Labs and implemented by nedjo. We probably need more of a battle plan and assigning dev tasks to people to get some of the other work done, as outlined by the recent poll results. Lastly, the concept of "verified" modules (e.g. image, event) that are non-core has been brought up a couple of times. Essentially, the question becomes, how do modules become verified? Some thoughts I've had are: * at least 2 "maintainers", both of which agree to commit patches regarding bugs, etc. * a commitment from those maintainers to keep updating/port to the next version * ??? Cheers, -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
Just wanted to say Earl that I've been following your work on your blog with aggregator/paggregator with interest. It's a core module that only sporadically gets attention.
As have I. I'm actually hoping that some of those changes make it into the core aggregator. I only have a handful of feeds and I've run into some of the same management problems that Earl did when creating his 'mega aggregator.' The aggregator module is really one of Drupal's impressive 'differentiating features'. --Jeff
I had brought up before that we might consider designated maintainers for core modules -- see http://drupal.org/node/34439 -- there are still the majority that are theoretically "maintained" by Dries. Dries, do you want to speak up and say which ones you *actually* want to maintain, which might be in need of an official maintainer, etc.?
Having 'official maintainers' matters for me: in the best case scenario people will bug the maintainer and not me. Other than being the official point of contact, very little changes. People become the official maintainer of a core module after they have been given the module some 'love', where 'love' implies that a steady stream of their patches made it into core. For example, I recently invited Cvgbe (Piotr Krukowiecki) to become the official PostgreSQL maintainer after he contributed a dozen PostgreSQL patches. Being the 'official maintainer' doesn't really matter for you (you, being a developer). What matters for you are your patches that make it into core. The more good patches, the higher you are on my list, the more weight you get, and the more trust you gain. Furthermore, for almost all of the core contributors, I know exactly what they are good at, so the weighting actually differs from topic to topic. For example, I may blindly trust Cvgbe's PostgreSQL contributions but I'll be a lot more conservative when he proposes a big forms API change. Don't ask me to write down the list, because not only is it per topic, it is also ever changing. For example, recently Richard Archer has done a number of great menu module patches that have been known to be hard, he demonstrated persistence, and he clearly communicated a vision; as a result, he gained quite a bit of trust with regard to the menu module. -- Dries Buytaert :: http://www.buytaert.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 12:28 AM, Dries Buytaert wrote:
Don't ask me to write down the list, because not only is it per topic, it is also ever changing. For example, recently Richard Archer has done a number of great menu module patches that have been known to be hard, he demonstrated persistence, and he clearly communicated a vision; as a result, he gained quite a bit of trust with regard to the menu module.
Richard Archer++ =) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDfldYgegMqdGlkasRAtlMAJ0ecNs0YzYkKbOaUf1ruGZ7ggUDywCeKsJB 60wL2fWevMsVcs8BCvDRmsI= =/xLU -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
Richard Archer++ =)
Having worked with Richard Archer on PHPLIB (if what I did could be called work), I knew he would be a good addition to the Drupal team. I was very happy to see his name appear on the dev email list. +1 indeed! :-) ..chrisxj
On Sat, 19 Nov 2005 00:59:37 +0100, Chris Johnson <chris@tinpixel.com> wrote:
Adrian Rossouw wrote:
Richard Archer++ =)
Having worked with Richard Archer on PHPLIB (if what I did could be called work), I knew he would be a good addition to the Drupal team. I was very happy to see his name appear on the dev email list.
A guy who out of the blue first does menu then plays patch pingpong with we on a forms API related patch? I was astonished. Big ++
On 18-Nov-05, at 2:28 PM, Dries Buytaert wrote:
I had brought up before that we might consider designated maintainers for core modules -- see http://drupal.org/node/34439 -- there are still the majority that are theoretically "maintained" by Dries. Dries, do you want to speak up and say which ones you *actually* want to maintain, which might be in need of an official maintainer, etc.?
Having 'official maintainers' matters for me: in the best case scenario people will bug the maintainer and not me. Other than being the official point of contact, very little changes.
Right. That's all that I meant. Later on you say "Don't ask me to write down the list"...I guess what I'm asking is if it would be useful to have the list for some more of the core modules. There is a certain responsibility in that case to look at patches for a particular core module, and then it is known by those people. e.g. James knows that he has to personally look at all Blog API bugs/ features/etc. Just as now, any that you feel don't have maintainers (i.e. people with enough trust to be responsible for them) still fall into the everybody looks at them/needs to +1 them. Or, of course, ones that you want to maintain yourself. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
On 19 Nov 2005, at 00:36, Boris Mann wrote:
I had brought up before that we might consider designated maintainers for core modules -- see http://drupal.org/node/34439 -- there are still the majority that are theoretically "maintained" by Dries. Dries, do you want to speak up and say which ones you *actually* want to maintain, which might be in need of an official maintainer, etc.?
Having 'official maintainers' matters for me: in the best case scenario people will bug the maintainer and not me. Other than being the official point of contact, very little changes.
Right. That's all that I meant. Later on you say "Don't ask me to write down the list"...I guess what I'm asking is if it would be useful to have the list for some more of the core modules. There is a certain responsibility in that case to look at patches for a particular core module, and then it is known by those people. e.g. James knows that he has to personally look at all Blog API bugs/ features/etc.
James is listed as the blogapi module maintainer, but he somewhat stopped caring about it, I think. He didn't look at any of the recent blogapi.module patches. In my book, James stopped doing core development months ago.
Just as now, any that you feel don't have maintainers (i.e. people with enough trust to be responsible for them) still fall into the everybody looks at them/needs to +1 them. Or, of course, ones that you want to maintain yourself.
Listing someone as the maintainer doesn't change a thing nor is it a guarantee for success. All it does, is associate an e-mail address with a module. If someone wants to be in the MAINTAINERS.txt, drop me a mail, or better yet, upload a patch against MAINTAINERS.txt. I'll try to update the MAINTAINERS.txt (remove some people, add some people) before I roll a Drupal 4.7.0 RC1. -- Dries Buytaert :: http://www.buytaert.net/
On 11/19/05 2:39 AM, Dries Buytaert wrote:
On 19 Nov 2005, at 00:36, Boris Mann wrote:
I had brought up before that we might consider designated maintainers for core modules -- see http://drupal.org/node/34439 -- there are still the majority that are theoretically "maintained" by Dries. Dries, do you want to speak up and say which ones you *actually* want to maintain, which might be in need of an official maintainer, etc.?
Having 'official maintainers' matters for me: in the best case scenario people will bug the maintainer and not me. Other than being the official point of contact, very little changes.
Right. That's all that I meant. Later on you say "Don't ask me to write down the list"...I guess what I'm asking is if it would be useful to have the list for some more of the core modules. There is a certain responsibility in that case to look at patches for a particular core module, and then it is known by those people. e.g. James knows that he has to personally look at all Blog API bugs/features/etc.
James is listed as the blogapi module maintainer, but he somewhat stopped caring about it, I think. He didn't look at any of the recent blogapi.module patches. In my book, James stopped doing core development months ago.
Say what?? -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 11/19/05 2:39 AM, Dries Buytaert wrote:
James is listed as the blogapi module maintainer, but he somewhat stopped caring about it, I think. He didn't look at any of
the recent
blogapi.module patches. In my book, James stopped doing core development months ago.
Say what??
I can say first-hand that James was in fact involved in the troubleshooting and fixing of the last round of blogapi patches. Even when he wasn't directly involved in the threads for a while, he was coordinating with at least a couple of us about the issues via irc. --Jeff
On 11/21/05 10:20 AM, Jeff Eaton wrote:
On 11/19/05 2:39 AM, Dries Buytaert wrote:
James is listed as the blogapi module maintainer, but he somewhat stopped caring about it, I think. He didn't look at any of the recent blogapi.module patches. In my book, James stopped doing core development months ago.
Say what??
I can say first-hand that James was in fact involved in the troubleshooting and fixing of the last round of blogapi patches. Even when he wasn't directly involved in the threads for a while, he was coordinating with at least a couple of us about the issues via irc.
yeah, we're all good. I think Dries had too much sun in Barcelona ;) -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
I can say first-hand that James was in fact involved in the troubleshooting and fixing of the last round of blogapi patches. Even when he wasn't directly involved in the threads for a while, he was coordinating with at least a couple of us about the issues via irc.
yeah, we're all good. I think Dries had too much sun in Barcelona ;)
Yes, I had. James did indeed work on blogapi.module; it just went under my radar while in Barcelona. -- Dries Buytaert :: http://www.buytaert.net/
Hi Please update http://drupal.org/node/23789 a little, you explain it so much better, then I do. Also, we could choose to make that page more prominent. All in all, i totally agree that this is a big problem, but I don't know a solution. You are right to state, that this /is/ a problem. But an example of where this collaboration worked well, was links [1]: Anyone doing anything with weblinks should *really* check that project. There are APIs tables, modules, hooks, and what more for your weblinks in there. But also; I think anyone needs to monitor the projects [2] and contact the author if someone checks in a project that does what your project has done for years already. Oh, and last, I think we could set up a smal team on drupal.org and get approx 20 people who can "unpublish" projects. This needs no code, just some guidelines. Unpublishing projects can be done after sommunication with an author and after a project was found unfit for drupal.org. Bèr Op vrijdag 18 november 2005 16:29, schreef Allie Micka:
The 4.7 / Forms API upgrade is going to create a learning curve for many module developers, and some of the less-active module owners may not have the time and inclination to make the switch. That could be good news.
A lot of these efforts are "learning experiences" that are not being maintained at all. Some of the authors can't be reached, and if you're too polite to overwrite those modules you start new. Some developers feel that it's more rewarding to have their name in lights than to collaborate on a module that's more useful and stable overall. Some people just don't play well with others.
As an alternative to upgrading, some module developers could look at modules with similar functionality and try to help upgrade and enhance those. Do we really need 3 Amazon modules? 6 "mail this thing" modules? (one of these is my fault) Can the Flikr Block module be part of the Flikr Module? The list is endless.
This is a big problem for new Drupal users and old timers alike. It's not clear which modules are being maintained and how well they work. A few months ago, I tried all the Amazon modules and discovered that each gave me about 60% of a solution. I finally just dropped the idea if using Amazon at all. I'm sure this sort of thing happens a lot, and we never even hear about it.
I'm not saying that any of these modules deserves to die, or that they can't possibly be bringing anything new to the table, but I would offer these suggestions:
- As part of the call for upgrades 4.7, recommend that module developers try to combine efforts - Encourage people to maintain TODO lists for modules so that others can understand overall goals and see if added functionality would be useful - Encourage people to archive and retire their abandoned projects from CVS.
Allie Micka pajunas interactive, inc. http://www.pajunas.com
scalable web hosting and open source strategies Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
One of the biggest selling points of Drupal (IMHO) is the sheer number of contributed modules (and developers behind them). One of the biggest drawbacks is the amount of stuff that doesn't work *right*. It seems that there are a number of forces at play here - 1) What is out there? While I love going through the list of contributed modules there is so much out there that I have no idea where to start sometimes. 2) Core vs. Contrib - This pattern seems to be mainly about general vs. specific - but it is also about quality vs. quantity. It seems that quality vs. quantity needs more attention. 3) Who is this product for? Drupal is a very mature product - but it seems like it hasn't grown up yet :) - which is kinda cool - and kinda infuriating. I think that there needs to be a better definition of who this product is for - is it for the people who spend most of their time developing/contributing to it? Is it for web developers? Is it for webmasters? Is it for end-users? At the end of the day we all sit somewhere in a very long chain which starts with dreamers and ends with a person at the end of a wire plunking at their keyboard. 4) How do things get done around here? The only sure way to do anything is to do it yourself - which is fine - but it limits participation (see 3 above). There are a bunch of different possible solutions to any given problem (like the one pointed out in Allie's email). However without a roadmap it is difficult to know which way to go. Here are some specific things that might work to solve this problem - 1) Right now there are three module categories -> core, modules, sandbox. Perhaps there should be another? "community modules" - being stuff that the "community" endorses? Perhaps by a straight up or down vote of contributors? I know this is radical. 2) There could be a "reviews" blog attached directly to each module - I'm sure this is an old discussion - sorry for bringing it up again. I would love to see Allie's notes from her investigation of the "Amazon" modules so I knew what was in and not in each module. IMHO Drupal is going through some growing pains - Dries pointed this out in Amsterdam when he talked about the phenominal growth of the community. There is a lot of work to be done. Here's one last idea - perhaps what is needed is a community manager? Someone who is committed to full-time work on Drupal and is directed by a clearly agreed upon set of deliverables. We would chip $$ in to pay for this as an experiment - and honestly I think that in a community this size it would be trivial to raise $$ to do this. Of course this entire email is worth less than silver :). Dan
The 4.7 / Forms API upgrade is going to create a learning curve for many module developers, and some of the less-active module owners may not have the time and inclination to make the switch. That could be good news.
A lot of these efforts are "learning experiences" that are not being maintained at all. Some of the authors can't be reached, and if you're too polite to overwrite those modules you start new. Some developers feel that it's more rewarding to have their name in lights than to collaborate on a module that's more useful and stable overall. Some people just don't play well with others.
As an alternative to upgrading, some module developers could look at modules with similar functionality and try to help upgrade and enhance those. Do we really need 3 Amazon modules? 6 "mail this thing" modules? (one of these is my fault) Can the Flikr Block module be part of the Flikr Module? The list is endless.
This is a big problem for new Drupal users and old timers alike. It's not clear which modules are being maintained and how well they work. A few months ago, I tried all the Amazon modules and discovered that each gave me about 60% of a solution. I finally just dropped the idea if using Amazon at all. I'm sure this sort of thing happens a lot, and we never even hear about it.
I'm not saying that any of these modules deserves to die, or that they can't possibly be bringing anything new to the table, but I would offer these suggestions:
- As part of the call for upgrades 4.7, recommend that module developers try to combine efforts - Encourage people to maintain TODO lists for modules so that others can understand overall goals and see if added functionality would be useful - Encourage people to archive and retire their abandoned projects from CVS.
Allie Micka pajunas interactive, inc. http://www.pajunas.com
scalable web hosting and open source strategies
Op vrijdag 18 november 2005 17:43, schreef Dan Robinson:
I think that there needs to be a better definition of who this product is for - is it for the people who spend most of their time developing/contributing to it?
One of the reasons Ruby on rails does so well, is because it has this VERY well defined. Thus they have a very targeted audience. We dont have this, which in some way is cool, but on the flipside makes it impossible to get Drupal "just right". A result of not being able to say: 'this is for Charlie, not for Joe' is that we can cater neither Charly nor Joe. And both are then annoyed in some way (Joe wants an online installer, Charlie wants a clean development platform, without all these options and unneeded bloat) And another result is these endless usabilty nitpickyish discussions; whether Foo should be called Bar, whether it should be an option, or rather a theme function etcetc. I, for myself, made a choice. For me, drupal is a Development platform. My modules will no longer 'just work'. All modules I develop from now on, will need some theming, some menu fiddling and maybe even some PHP blocks and/or pages, to be full featured. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
On Fri, Nov 18, 2005 at 08:43:22AM -0800, Dan Robinson wrote:
1) What is out there? While I love going through the list of contributed modules there is so much out there that I have no idea where to start sometimes.
Some categorization would be nice. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
IMHO Drupal is going through some growing pains - Dries pointed this out in Amsterdam when he talked about the phenominal growth of the community. There is a lot of work to be done.
Correct. Bear in mind that there always have been growing pains, and that there always will be growing pains. It's perfectly normal. What matters is how we counter the growing pains. To answer your questions: 1. Download page: we are working on improving the download page. 2. Quantity vs quality: we are working on project ratings. (Check with Boris for the latest details?) 3. Who is this product for? Drupal is for users who want to setup a website _and_ for developers who need a platform. 4. How do things get done around here? Either you do it yourself, or you work on it with others. So we are working on the growing pains -- even though you might not have noticed. -- Dries Buytaert :: http://www.buytaert.net/
IMHO Drupal is going through some growing pains - Dries pointed this out in Amsterdam when he talked about the phenominal growth of the community. There is a lot of work to be done.
Correct. Bear in mind that there always have been growing pains, and that there always will be growing pains. It's perfectly normal. What matters is how we counter the growing pains.
agreed. However as the speed of growth accelerates it will place new strains on the community - IMHO.
To answer your questions:
1. Download page: we are working on improving the download page.
great is there a discussion about this somewhere?
2. Quantity vs quality: we are working on project ratings. (Check with Boris for the latest details?)
great.
3. Who is this product for? Drupal is for users who want to setup a website _and_ for developers who need a platform.
That's reasonable - but pretty ambitious. There aren't many products out there that are developers tools as well as non-web developers tools. As a matter of fact I can't think of any off hand at all. This doesn't mean that Drupal can't do it - it just means that it is new territory (the fun kind).
4. How do things get done around here? Either you do it yourself, or you work on it with others.
So we are working on the growing pains -- even though you might not have noticed.
no I actually have noticed - and everyone is doing a great job. I did not mean to be negative nor critical - sorry if it came off that way.
-- Dries Buytaert :: http://www.buytaert.net/
1. Download page: we are working on improving the download page.
great is there a discussion about this somewhere?
A first step patch was applied to the Project module to enable full categorization of projects (e.g., with multiple vocabularies), see http://drupal.org/node/32121. An issue and draft patch for the next steps - sorting by date and category as well as alphabetically - is at: http://drupal.org/node/33803 I've been working this week on a revised patch and should have it posted next week. Comments meantime would be welcome. And Kieran at CivicSpace Labs is organizing a 'card sort' approach to deciding how to classify existing modules and themes. There is also a proposal to implement (opt in) XML-RPC calls between Drupal installs and drupal.org, see issue at http://drupal.org/node/34108. I'm beginning work on this issue--other ideas and contributions very welcome.
From that issue:
Dries: "rather than using explicit rating where users have to submit a score by hand, I'd prefer to use automatic ratings. I envision some XML-RPC function that posts a list of one's modules to Drupal.org. Drupal.org uses that to update/compile ratings. A key advantage is that: (i) it needs no manual rating/interaction (no interface cruft) (ii) easy to make it temporal so that the ratings automatically adapt over time (iii) better matches the reality." ... We could also extend this to enable drupal installs to query drupal.org for newer versions of installed modules, recent bugfixes, newly released modules, etc., thus providing significant benefits to the installed base.
2005/11/19, Nedjo Rogers <nedjo@islandnet.com>:
We could also extend this to enable drupal installs to query drupal.org for newer versions of installed modules, recent bugfixes, newly released modules, etc., thus providing significant benefits to the installed base.
This will be a great enhancement (also for themes)
-- vi is a real WYSIWYG editor: you see text, you get text.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 12:49 PM, Gildas COTOMALE wrote:
2005/11/19, Nedjo Rogers <nedjo@islandnet.com>:
We could also extend this to enable drupal installs to query drupal.org for newer versions of installed modules, recent bugfixes, newly released modules, etc., thus providing significant benefits to the installed base.
This will be a great enhancement (also for themes)
It's already planned. http://drupal.org/install-system-overview I will be writing DEP's about each of the different phases still outstanding pretty soon. (once 4.7 is out) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDfwXWgegMqdGlkasRAj+CAKDHOcrHOAAjfOtLos3AIsgeWn3EVgCfeptS aFk8eEGsR1d4retNNHacBl0= =55L8 -----END PGP SIGNATURE-----
Correct. Bear in mind that there always have been growing pains, and that there always will be growing pains. It's perfectly normal. What matters is how we counter the growing pains.
agreed. However as the speed of growth accelerates it will place new strains on the community - IMHO.
Sure. As we grow bigger, the challenges we face grow bigger too. It isn't any different in life. When you are a kid, the challenges you face look big (eg. making it through high school, getting grades, breaking up with a girlfriend) but when you reflect on them at later age, they are peanuts. At later age, you have bigger challenges (getting a job, running a company, paying a loan, taking care of your family). It hasn't been any different in Drupal's lifecycle. To me, growing is learning to deal with bigger challenges (or growing pains).
3. Who is this product for? Drupal is for users who want to setup a website _and_ for developers who need a platform.
That's reasonable - but pretty ambitious. There aren't many products out there that are developers tools as well as non-web developers tools. As a matter of fact I can't think of any off hand at all. This doesn't mean that Drupal can't do it - it just means that it is new territory (the fun kind).
I don't think it is ambitious; it is merely logical. If we focus on making Drupal a great developer platform, then that implies that other developers use it to make products. If they can or have to make products using Drupal, we should be able to make a base product too, shouldn't we? In fact, by making a base product, we get better understanding of the shortcomings. Furthermore, by being (or attracting) both users and developers we have our own feedback loop. As you said, it makes for a much more interesting situation and a diverse community. I'd say that is how most -- if not all -- open source communities work so there are actually plenty of examples out there. (It is also why I fundamentally disagree with the stuff Ber wrote about making a choice and giving up one aspect.) -- Dries Buytaert :: http://www.buytaert.net/
Op zaterdag 19 november 2005 09:04, schreef Dries Buytaert:
(It is also why I fundamentally disagree with the stuff Ber wrote about making a choice and giving up one aspect.)
I think we don't disagree. A diverse community is very good. But IMHO that communtiy does not have to livz all on one place. Linux's distro system works great: you have a huge and diverse community. When I got kernelfreezeson my new/odd AMD, I reported that to mandrake, they told me it went all the way up to the kernel guys (woo). So, while I have to only talk to folks trained for helpdesks (mandrake payed helpdesk), I am still part of the community. I strongly beleive in Drupal itself as a 'nothing in particular' (not as much as RoR, but maybe in the direction of typo3-but-then-easy). Around that, a flock of distro's that are very particular can be maintained. Too often do I hear the comlpain that 'Movable Type is much better then Drupal'. This is simply untrue. Not because MT is better/worse, but because Drupal cannot be compared to a focused CMS. Now, if we would have Dan Developer maintaining a (maintained) drupalBLOG solely for blogging, al these endless discussions about taxonomy/themes/options/usability being too hard to grok would stop. But also DrupalBLOG could be compared to MT, and would do very, very well. ATM the model is Joe User <-> Drupal While, the model could be: Joe User <-> Dan Developer <-> Drupal. We don't loose feedback. Instead: we then know that when Dan Developer speaks, or comes with a patch, he does so for hundreds (of thousands) of users. While in our current situation, there is a lot of buzz. And Joe Users voice (or issue or patch) is lost in that noise. I for one, know, that when Boris/James/Adrian/Roland say that we really need [tm] clean URLS in core, that that weights far more, then when I say "i want theme_foo to get more info". It is because Bright talks to real users on a daily base. And not only to these few users that manage to fight themselves into the forums. How many of you do not think 'RTFM' when someone asks "how do I delete a user". That Question itself indeed is a RTFM Q. But it is also valuable, because if fiften people a week answer that, we have found another usaility bug. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
Dan Robinson wrote:
2) Core vs. Contrib - This pattern seems to be mainly about general vs. specific - but it is also about quality vs. quantity. It seems that quality vs. quantity needs more attention. 3) Who is this product for? Drupal is a very mature product - but it seems like it hasn't grown up yet :) - which is kinda cool - and kinda infuriating. I think that there needs to be a better definition of who this product is for - is it for the people who spend most of their time developing/contributing to it? Is it for web developers? Is it for webmasters? Is it for end-users?
I'd say "Drupal is for everybody"...but what I think needs some definition is the concept of "Drupal", "Drupal core" and who/what it is for... Then we can build on that, maybe having some distributions. I've post some other e-mail abt core vs. distributions.. Actually I'd point all new users who have trouble setting up Drupal, directly to CivicSpace -which I do sometimes :-) But in general, we should build upon the idea of 'distributions' better than 'making Drupal core user friendly'
4) How do things get done around here? The only sure way to do anything is to do it yourself - which is fine - but it limits participation (see 3 above). There are a bunch of different possible solutions to any given problem (like the one pointed out in Allie's email). However without a roadmap it is difficult to know which way to go.
Yes, a roadmap would be great. And some more organization and coordination too -but not too much :-). Actually there's been a number of posts lately about how we could better organize ourselves.
Here are some specific things that might work to solve this problem -
1) Right now there are three module categories -> core, modules, sandbox. Perhaps there should be another? "community modules" - being stuff that the "community" endorses? Perhaps by a straight up or down vote of contributors? I know this is radical.
I'd like to have: - core: minimum cms engine with few basic modules - standard modules: a few more than the ones that are currently in core, but these must be the ones maintanined by core developers with 'core quality' - contributed modules: all the rest (and same for themes) As you can see, my idea is not based on ratings -which would be nice to have anyway- , but on who with which standards maintains it. IMHO ratings provided by users are too prone to put features before quality and stability.
2) There could be a "reviews" blog attached directly to each module - I'm sure this is an old discussion - sorry for bringing it up again. I would love to see Allie's notes from her investigation of the "Amazon" modules so I knew what was in and not in each module.
Let´s bring it up again and again until its there :-) I haven't used too much the 'project module' but my question is: as 'projects' seem to be nodes, is it that difficult to enable comments -call it reviews- on them?
Op zaterdag 19 november 2005 21:22, schreef Jose A. Reyero:
IMHO ratings provided by users are too prone to put features before quality and stability.
This, is a very interesting idea. currently, IMO, Drupal is so stable, and solid, because we /don't/ have a rating system for core. In the same time, Drupal contribs range from awfull to great yet are in the same place. I think a (technically) worked out idea for this "second contrib" thing is great. I volunteer for joining some folks to get that going. Anyone else? Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
Well, this 'users like features vs. quality and stability' is actually an old story: It is the Windows vs. Linux saga. And guess which one is the more used? :-( So... do we want to become rich, like Bill Gates, or to produce a world class bullet proof system, like Linux/Linus ? ;-) Just joking.... I volunteer for that too :-) Bèr Kessels wrote:
Op zaterdag 19 november 2005 21:22, schreef Jose A. Reyero:
IMHO ratings provided by users are too prone to put features before quality and stability.
This, is a very interesting idea. currently, IMO, Drupal is so stable, and solid, because we /don't/ have a rating system for core. In the same time, Drupal contribs range from awfull to great yet are in the same place.
I think a (technically) worked out idea for this "second contrib" thing is great. I volunteer for joining some folks to get that going. Anyone else?
Bèr
participants (16)
-
Adrian Rossouw -
Allie Micka -
Boris Mann -
Bèr Kessels -
Chris Johnson -
Dan Robinson -
Dries Buytaert -
Dries Buytaert -
Earl Dunovant -
Gildas COTOMALE -
James Walker -
Jeff Eaton -
Jose A. Reyero -
Karoly Negyesi -
Nedjo Rogers -
piotr＠mallorn.ii.uj.edu.pl