|Subject:||Re: [Dolibarr-dev] Upgrade work methods|
|Date:||Tue, 15 Jan 2019 10:48:59 +0000|
Hello all,I agree that a slack group or an IRC channel would be great to discuss ;)Also agree with about everything you said in your first email Mickaël.In my opinion, it would be great to enforce a coding standard for the project.This has already been discussed here : https://github.com/Dolibarr/dolibarr/issues/6186It can be pretty easy with tools like Stickler CI or other static analyzer tools that can be run through CI (Travis or other tools) like phpstan, phan and phpcs.I continue to think that making exceptions to PSR2 like written in https://wiki.dolibarr.org/index.php/Language_and_development_rules#PHP is not the way to go ...We just need to clean the code to pass PSR2 for every file and enforce the coding standard to every PR through CI to not reintroduce tabs again.Another problem is also the growing number of issues not being classified.An issue is opened here https://github.com/Dolibarr/dolibarr/issues/9306 and it would be great to make progress on that ;)JeanCe message est signé pour en garantir l'authenticité.
Vous pouvez vérifier l'authenticité de ce message (et répondre de façon sécurisée en chiffrant votre réponse) à l'aide de la clé publique attachée à ce message.‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐Le mardi 15 janvier 2019 11:09, Mickaël PENHARD <address@hidden> a écrit :How does coders works actually ? I see that it's eldy who make most of the commit history (I suppose the most of the codebase too).I see quite often message about people who are open to help/contribute, that a good sign, does there is a platform/way to speak about it in live ? Like a slack group, which will be more appropriate in this case because there is a need to discuss a lot about what next will be.Organization (https://wiki.dolibarr.org/index.php/Statuts_de_l%27association) is still alive ? The last board meeting seem to be from 2013 ?Regards,Mickaël PENHARDAlvaria SASU - CEOLe lun. 14 janv. 2019 à 21:04, Sasa Ostrouska <address@hidden> a écrit :On Mon, Jan 14, 2019 at 6:37 PM Mickaël PENHARD <address@hidden> wrote:Hi,I was thinking to be kind(positive), sorry if it's not interpreted like that.Regards,Mickaël PENHARDAlvaria SASU - CEOLe lun. 14 janv. 2019 à 18:32, Christophe Battarel <address@hidden> a écrit :
Thank you Mickaël for sharing your thoughts with us.
I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.
And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...
On 14/01/2019 17:31, Mickaël PENHARD wrote:Hi maintainers,Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).Like this commit :Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).Here a simple list :1. Commit != CTRL+S2. Commit message should be clear about what it fix/update3. Stop merge commit on all this versioning ecosystem which not usefull at all4. Everytime a file is edit, CLEAN IT remove all tabs => space5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)7. Stop any other new development before everything which is available really work, like accountancy8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/189117911. Avoid multi copy of the same code12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.13. etc...Thanks for reading,Best regards,Mickaël PENHARDAlvaria SASU - CEOHi Mickel, great good points from my point of view. At least on the translate all to english would really be good to see.Step by step we can come to some of those issues be solved. I am ready to help with. But at the end on an OSS softwareproject with a lot of people working on it its really difficult to make sure everybody proposes with the same rules his code.RgdsSaxa_______________________________________________Dolibarr-dev mailing list
publickey - firstname.lastname@example.org - 0x259843BA.asc
Description: OpenPGP digital signature
|[Prev in Thread]||Current Thread||[Next in Thread]|