Ber , Morbus and all, Would you consider stepping back a moment and thinking as a non- developer? This is the kind of decision that ought to fall on the shoulders of a user-relations team and not developers. I worked at Colgate-Palmolive as the tech and communications writer for their Consumer Affairs department. Colgate-Palmolive is the largest manufacturer of toothpaste in the world, among many other products. They produce everything from dentistry pharmaceuticals to dog food. For four years I wrote the manual on how to handle all sorts of inquiries, complaints and suggestions coming from consumers. My job, was to write human-readable instructions and communications guides for our Consummer Affairs representatives. I was dead against scripts because they show a lack of training and understanding of the products and consumers; and at that time my bosses agreed. Knowledge of all products, past and present, was a part of the training for our reps. I was instrumental in making that happen in the least of techie ways given that this was BEFORE the internet was used by major companies for doing business (1994). I mean, the system I was using was written in a pre-WYSIWYG DOS system. So you can imagine how "cutting edge" and scary for non-techie people that must have been. My job was twofold : I had to help transition consumer-to- company communications from an analog system of communications to this new digital system while also transitioning and streamlining the internal communications all departments affected by consumers (Legal, Marketing, Sales, R&D). One of the biggest percentages of communications was on discontinued products. People would always call or write about products the company had stopped manufacturing for years. Loyal consumers sensing the disappearance of the product would stock up on it. CP spent a lot of time and effort on these particular people. Why? Because if consumers were bound to look for that product high and low it meant they were loyal consumers. The challenge for the company was to transition those consumers to newer products and keep them as word-of- mouth evangelizers. One of the most frustrating aspects of working with Drupal is the lack of forethought on word-of-mouth evangelizing and user loyalty that goes in the development, implementation and the dissemination of the product --and yes, I am calling Drupal a product because that is what it is. Given that you have an open source product it is a mystery to me why you have decided to disappear from your site the history of the product's development. This is a huge loss for future developers who come to the site looking to learn more about the product. If it were up to me, I'd curate a whole section on the development of Drupal. I'd keep each release for historical documentation and, if possible, annotate it with some commentary from not just from developer but particularly from loyal users of Drupal. A product's success does not lie just on it's design or development. A product's success lies on it's word-of-mouth reputation among users. Word-of-mouth is what makes or breaks products and it's why most of the shittiest products succeed. Toys like "Pet Rock" to celebrities like "Paris Hilton" make it all by the grace of their word-of-mouth god. It's not fair but it's what happens in the real world. Back to Ber and Morbuss and most of the developers of Drupal : I just think that as developers, you're way of thinking works best with code. I honestly do not know what it is about this group of developers but you definitely think and work differently than developers in the Movabletype, TextPattern and WordPress development groups. For me, as someone who has been 'looking from the outside in', in all these groups, it's really interesting to see how differently coders work from one product to another ---and it proves software development is a very personal and subjective process; even when done by a group of people. You have a good product and a growing base of non-developers eager to use it. Open archival access to your past success needs to be an important part of how you engage the people who use Drupal. It should be integral to your documentation, which gets better with each passing day. You still need people who are part of core who deal solely with community/user/consumer issues and think about these things. You need more than one person so that developers don't get the opportunity to gang against him/her (as in the Dilbert effect). Which is why, these people need to be regarded as part of the core group of developers. Yes, I do have to agree with the common belief that it's rare to find developers who understand the nuances of community/consumer affairs. They are out there, and you do have some right here within your ranks. But as a development groups go, you have to decide that dealing with the community is just as important as dealing with the code. And more importantly, you need decide on a process on how to go about that, even if it means developers won't be part of that decision making. Which is why I insist : Give away those decisions to people who can do that person-to-person heavy lifting. It will make Drupal.org an infinitely better experience. Best, l i z a sabater www.lizasabater.com AIM - cultkitdiva SKYPE - lizasabater TEL - 646.552.7365 On 27.May.2006, at 11:36, Khalid B wrote:
On 5/27/06, Morbus Iff <morbus@disobey.com> wrote:
Why do you need to remove this stuff? There are those who like I have
Leaving it up is, to some, an admission of *support*.
Lisa
Also, remember that 4.5 is not patched for the latest exploits, so it is very dangerous to continue to run with that, regardless if it is supported or not ...