[Vtigercrm-developers] Community help needed

Richie richie at vtiger.com
Thu Sep 28 02:37:29 PDT 2006


Ok I am back again! 
 
A wiki will be maintained for the other products with which vtiger is in the works to be integrated with. This should be up soon. 
 
A patch contribution process mail has been sent to the mailing list and this too will be put in the wiki. 
 
Instructions have been sent to shutdown the developer forum and move them to the mailing list. Anyone having objection to this please escalate now. This will happen over a period of 1 week as I need to get others reactions to this. 
 
Dennis, your trac account has been created. Let us see how many patches come from you :-)! Hope you keep Philip busy over here integrating the patches. I hope the mail post on the Patch Contribution process and wiki on this issue lays to rest the issues with the Patch process. 
 
Your 'Comments' post has been taken to heart. Instructions have been sent to ensure that the maligned code is fixed and with proper comments. It also has been integrated into the development process. 
 
All patch contributions will be intimated of their status soon. 
 
The Subversion How To part is something that I need help from all the masters concerned. JeffK, your help needed. 
 
Richie 





---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- 

  

 >c) We need information on who all have done integration with any accounting> softwares out there as it seems to be the most commonly asked query

Some sort of integration between vtiger and Microsoft Great Plains (aka Dynamics) is on my list of requirements.
 >d) Make the product smaller in size still. I feel, the product is even now 
> too big. 

I don't see the value here.... The size isn't currently a problem, and there are bugs to fix and features to add.

>e) Language packs. We are running in circles with this issue. 
> We have tested and tested and still not able 
> to reach a point where we can rest relaxed. We need help in this. 

More to the point, vtiger needs to support per-user localization. I need to be able to have the interface present Japanese to the Japan office, German to the German office, etc etc **while still pointing to the same core database** Jens' work on multiple sales offices is the start of this.

>k) More information needed on where all vtiger lacks so that we can start 
> working on those areas

You can start by making it easier for those of us with custom code forks to merge our improvements back into the core. There has been some movement in this area (I noticed that some of my patches made it into 5.0GA) but we still don't have a good process for getting patches into core. I keep getting conflicting answers on what the process is, and movement on some fronts (I still don't have a Trac ID) has been slow.

>p) Achieve twice the popularity by the end of this calendar year. 
>vtiger needs to spread virally to all the corners of the world. 
> Tell me what can we do to achieve this. I have been spending sleepless
> nights for far too long on this.

It's a total non-issue. It's not important. The better the product is, the more people will use it. Word of mouth is your best friend - look at Linux
In my experienced opinion, the reason why Linux has been so successful is that Linus has been very good at establishing working development practices that let anybody hack on the kernel and see their improvements make it back into the core on a very short timeframe - assuming they meet his non-trivial quality requirements. The easier you make it for community members to add functionality to the core, the more people will work on the core, the better the product gets, and the more end users use the product.

It's a positive feedback loop that brings nothing but Sweet Crunchy Goodness.

Here are my suggestions:

1) Adopt this mailing list as THE SINGLE LOCATION for vtiger developers to discuss the code. Shut down the corner of the forums for developers. Shut down any place other than this list for users to talk to developers about bugs. Effectively, make this list the vtiger equivalent to linux-kernel. That's not to say that maybe in the future there will be sublists... but for now, the developer community is too fragmented and there's no single accepted common discussion clearing house. Make it this list - good enough for Linus, good enough for us.

2) Develop a procedure for patch submission. There needs to be a way for Joe Random Developer, who has been maintaining his own installation of vtiger for God knows how long, to submit a patch that fixes a bug and get it into the main trunk with the minimum amount of overhead on his part. In the Linux kernel, it is possible to send a patch to linux-kernel or even direct to Linus, and if it fixes a problem, it gets applied with no other interaction save an acknowledgement that the patch was applied - no bug in Trac, no login IDs, no nothing. In order to make effective use of community developers, you need to make getting their work into the main trunk as effortless as possible.

3) That's not to say that bug trackers like Trac or Bugzilla ***CANNOT*** be used (they can be very useful) but don't ***REQUIRE*** their use.

4) Work out a best practice for the use of Subversion, document it in extreme, trivial detail as a HOWTO, and publish it on the wiki. Take the point of view of a developer hacking on a live install of vtiger - how can Subversion be best used to make his life easier? That probably means modifying the core tarball installer deal so that it puts the vtiger code into apache/htdocs/vtigerCRM/trunk

5) Go through the current codebase, and fix all the bugs you can. This takes priority over themes, advertising, and all the rest.
6) Comment, comment, comment! Things have improved on this front, but could still be better. I know that some of my patches that were applied preserved my comments (this is GOOD) but at least one was re-implemented (using a odd method) and not only was the new method NOT commented, my comments were stripped as well. So now there is new functionality in the code with NO record of who added it, what it does, or why a given method was used in preference to any other method. My rule of thumb is that NO change is made to the code without a corresponding comment - ENFORCE THAT.

DG 

_______________________________________________
Get started with Online collaboration office & productivity tools - http://zoho.com?vt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060928/16e13395/attachment-0004.html 
-------------- next part --------------
***********************************************************************
          Confidentiality Notice

The information contained in his electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Adventnet immediately and destroy all copies of this message and any attachments.
***********************************************************************


More information about the vtigercrm-developers mailing list