I have written this post because I was asked to do it, but I am not the first ideator. The ideator of this initiative is aneilaDesign (Daniela). If this initiative will go well, then she has to have all the Glory for this initiative and not me. Please do not contact YobiLab for this initiative. I am just a person interested in this initiative. I will help you as any other person here will do only by commenting below. Also as written in the Disclaimers below, there is NOT an head/proprietor/leader of this initiative. All the people interested will support and give answers when available. Do not contact any of them personally for this Etiquette. Thank you.

---------------------------------------------------------------------------------------------------------------------

This is not an error. I think this should be the right section for this Note: Ideas and Dreams.

I am here not talking only for myself, I am now writing for some other developers and designers here, who asked to me to open this Note and I find myself totally agreeing with them.

I think and I hope they will be here soon posting some other things.

We had a new idea, maybe a Dream, that we really want to share with all the developers and designers of this community:

The Development Etiquette.

Yes, sure, we have to respect the Boonex rules, or at least we should, but there are some other things we should look at in order to make the work easier for us and for our customers.

So lets turn it into reality.

What we think the Development Etiquette should include is:

1) CSS coding way:

Fonts, styles, colors, borders, buttons etc.. we have to use the default Dolphin classes. Many modules we made are using our own CSS classes. This will comport issues in the custom templates of the customers and it will always require an additional work on them. It always happens because every customer has or will have a custom template. So we need to use the Dolphin general CSS classes to make sure we will not have any incompatibility with the custom templates.

Any other necessary class the CSS of the module will need to use, should not be coded in a way that will interfer with the general Dolphin CSS classes. It includes, but not exclusively: font colors, font sizes, font styles, borders, background colors-images, thumbnails modifications and in general any other attribute that will make a change in the custom template.

2) PHP Coding way related to the Template system:

-When creating new pages, in the Main section only the Content should be modded.

-No changes are allowed on the designbox, only what is inside the content of the designbox should be modded.

-The HTML code and the CSS code should not be Ever included in the PHP code. The HTML code and the CSS code should be written in the specific files.

-We should not make floating Elements without having them placed in a specific container. Only lightboxes and similars are allowed to float wherever on the template.

-When creating inputs, submit buttons and similars we should use the default Dolphin ones and not using our own classes with different backgrounds-images.

-Modification on the scripts files should always be made inside the custom template and not in the base folder.

-The customer should be always noticed of any change we have made on a Dolphin Default file. We will have to create a folder inside the server of the customer with a .TXT file where each of us should at least write where a change has been made and why.

-Any of the above requirements are also mandatory for the modifications on any Boonex Module.

3) PHP coding way:

-No modifications of the Dolphin Default files are permitted. If any change on the default files is necessary then this change should be properly written in the .TXT file as explained above.

-Every module should be coded in the way Boonex requires.

-Installation of each module should be easy and should not include more than 1-2 steps for the customer when possible.

-Insertions, Alterations and similars should be placed in the SQL file and should run only by the Dolphin Admin Panel.

-PHP code should be written in a way that will not eat all the server resources. Each PHP code should be as much smarter as possible, the same applies for mySQL queries, insertions, alterations and similars.

-Each module should always include the english language file. Each module should not have any missing language string. Also the languages strings should be written in a way that the customer will be able to easily modify them.

The above ones are only the very basic requirements. Every developer/designer interested in being part of this Development Etiquette should provide other requirements, that would be globally reviewed and then accepted.

Edited 25/06/2011

4) Licensing:

-Licenses should be provided in a simple way. The customer should be able to understand how and when is necessary to get a license for our module.

-The license system we are adopting must run on a secure server with at least 2 GB of RAM.

-We must provide to the user the opportunity to change the domain associated to the license. Licenses can be for One Domain. But if the customer requires to change a specific domain name with another one we have to give this oppurtunity. We cannot use such restriction.

-Continuos remote checks are not allowed as well.

5) Encryption:

Encryption is possible to protect our own work.

- CSS, HTML, Javascript, jQuery code should not be encrypted, ever.

- If possible only the Core of the module should be encrypted and not the entire code, in order to give the possibility to the customer to change the code where needed, after a proper communication to you, if the module is commercial.

6) Support:

-We should be available at least 5 days of the week

-We should be able to provide answers by mail or PM at least every 24 hours

-We should always open a specifc support Forum in the proper section for EACH module we sell on the market

-Updates or Upgrades should be released for free for each customer when already has a previous version of the module/template. This also applies for new versions of Dolphin. If the module you are selling is the same for Different versions of Dolphin, then the customer can claim it for free. Updating the module for a new version of Dolphin is required if even only one customer (that has already bought your module) will require that. (Edited : 25/06/2011)

-If we are going to not be available for a certain period, this should be well written in your Boonex Profile. We reject unsupported profiles for over 2 weeks.

7) Branding:

Logo Branding is permitted only for non-commercial scripts

-No Logos, Names, Links should be in the code if you are selling a commercial product. This applies both on front-end and back-end.

-If for any reason you must include your Brand, that must be specified in the Market post IN BOLD

-The name of the module that will appear in the back-end and in the URL should not contain our Name or TradeMark. The Name of the module should not include in any way our Brand.

-Modules should be listed under the "Modules" tab in the backend. If for any reason we have to use another tab for our module, that should not ever include our Brand.

-The name of the module should be "generic". We can give a name to the module on the Market Post. We cannot do the same in the Module itself. This is also to avoid a "Way for Branding" in the customer admin panel or URL.

8) Product description:

The description of the product must be easy to understand. We should include any possible detail. Also a Chagelog is required when we are providing different versions of the same module. In the description we should include IN BOLD anything that differs from these requirements. We should also explain why there are differences. Also we should make a notice here if you are making a module that is different for any reason from these requirements. This should not happen, only if this is necessary, and that should be properly noticed and written, or we will be immediately rejected!

-Every developer should have a Demo site where all the modules can be properly tested.

DISCLAIMERS:

Attention. This initiative is NOT supported by a specific developer/designer/member. This is an initiative where all the people can participate. This initiative has the only object to make a better way of coding/supporting/etc, in order to make our lifes easier. You cannot contact any person specifically. You should always write an issue in this post or in any other relative post, the first person available will give you an answer. So please do not feel any of us responsible for any issue you may have. Any developer/designer works here individually and the Development Etiquette does not have any control on that. Developers here can apply or not to this initiative, this is not Mandatory and this is not IN ANY WAY related to the Boonex Company and Products. This is an indipendent initiative, so please do not contact the Boonex Administrators in the case you will have any problem with this Etiquette. They are not going to answer. Also if a developer working under this initiative will do something wrong you will have to solve the issue with him before. If you do not find a way to solve the issue with this developer then please come here and add your report. The Etiquette will support ONLY THE ACCEPTED REQUIREMENTS ABOVE. We are not going to support any issue you will have that is not written here as a requirement.

Being part of the Development Etiquette:

It means having the responsibility of your own work and to accept any of the accepted requirements. Developers/Designers not following the above requirements will be rejected.

The big part of us will have to modify the existing modules to match the above requirements, so we have decided to apply the requirements only on new versions of our existing modules or on new modules we are going to sell.

We do not have to modify our exisintg modules, you are very welcome if you will do that, but this is not mandatory. But we will have to follow the above requirements on any of the modules we will sell after being part of the Development Etiquette.

All what is "should" is also a "must". If for any reason we are not following the above "shoulds", we will be immediately rejected. The customers have the power here. This statement will be always visible. If a customer reports an issue, that will be enough to be rejected after a proper verification.

The Development Etiquette:

If you are going to accept the above requirements and if you are going to post some others, then please add your reply on this Note.

You will receive a Seal of the Development Etiquette to use on your own profile.

That would represent for you the responsibility of being part of the Development Etiquette, and for the customers the guarantee you are following some of the most important requirements for a good work.

We will do some reviews by talking with the customers maybe every 2 or 3 months. Each of us can be rejected in any time and the Seal will not have any value in the case that the customers are not satisfied of our work.

The list of the Developers/Designers actively working under the Development Etiquette will be provided every month.

The Seal will be designed by aneilaDesign and we will provide that as soon as possible.

Please share your thoughts about this initiative.

IMPORTANT: "WE" are all the developers/designers interested in this initiative. You can be a part of "WE" as soon as you will reply to this Note. There is not an head here. Each of us is responsible of his own work. The customers will take the final decisions.

Also if you are not a developer/designer but you are interested in this initiative you are very welcome to share your thoughts and requirements with us.

Thank you