Contributing to Revolution and accelerating its ETA [split from UI change thrd]

I did a search on pretty printers aka code beautifiers for PHP and found this:

Beautify PHP (version 0.5.0, 08.05.2003)
http://www.bierkandt.org/beautify/
Written in PHP4. I don’t know if it will reformat PHP5-code correctly.

PEAR::PHP_Beautifier (0.1.13 (beta) 2007-02-14)
http://pear.php.net/package/PHP_Beautifier/
Rewrite of "Beautify PHP" in PHP5. Supports formatting of PHP4 and PHP5.

I suppose it would be a requirement that it runs on PHP4 since MODx itself does so.
(Or is it safe to assume that all developers have PHP5 available?)

Regarding the SVN hook I have no experience. But I’ve done a bit of research, and from what I read I think the right way would be to implement a pre-commit hook that checks if the commit conforms to the coding style, and if not reject the commit. Then it’s up to the developer to run the code beautifier before committing. (The pre-commit hook could be implemented simply by running the beautifier on the committed code and reject if the result doesn’t match the committed code.)

The reason for not modifying the commit to match the coding style in the pre-commit hook is that this would screw up the working copy.

Hmm...I am definitely going to use this to Beautify my PHP code

Yeah, after some additional thought and looking at the results of those pretty printers, nevermind on the pre-commit hook. Let’s just respect the coding style of the author and move on for now. When we have more time/resources/etc. we can worry with niceties like this to make everyone happy.

Quote from: OpenGeek at Jan 25, 2008, 03:13 PM

Yeah, after some additional thought and looking at the results of those pretty printers, nevermind on the pre-commit hook. Let’s just respect the coding style of the author and move on for now. When we have more time/resources/etc. we can worry with niceties like this to make everyone happy.

I guess I’m arguing that if there’s an available SVN hook, it would make sense to implement the tab and line ending conversion now and worry about pretty code later.

Bob

Those "pretty printers" are the hooks. The idea is that no matter how I reformat my local working copy with whitespace, bracket on same-line or new-line, etc., when checked-in, it would be forced back to the standard formatting, thus avoiding unnecessary whitespace conflicts when merging (resolving these constitutes 75% or more of the time spent merging). How that affects the working copy of the user, well, it would probably create local conflict problems if they reformat it in a way that SVN considers a diff, but it’s really the only solution I’m willing to accept if everyone cannot accept my coding style on this code I’ve contributed.

And this is definitely low priority IMHO...

I lost track of the discussion when coding standards started to be discussed, but I totally agree with a comment way back on the first or second page that said we need to market the CMS better. I am looking around for buttons that say "Made with ModX" or something similar so I can tag my website with it so people can take a gander at this beautiful CMS.

But what I wanted to ask is how can we solicit more people to come on the production/programming side of things?
Money is obviously the thing that every project needs, but is there any place where we can post a kind of "volunteer" listing for people that want to test their skills and contribute to a great project?

I have a year and half left before I get on the state bar...if this project stays alive, as I know it will, you guys better get ready for a big donation from a lawyer on the east coast...lol. Don’t hold your breath, but I just wish I could give a million dollars to this thing and have it take off! It deserves the best.

Quote from: Sulman at Jan 27, 2008, 07:19 PM

But what I wanted to ask is how can we solicit more people to come on the production/programming side of things?

This is one of the major goals of the rewrite itself; the current MODx code, though extremely useful and agile in it’s simplicity has some issues I consider a barrier to it’s sustainability. For instance, I believe the API is extremely inconsistent and unintuitive, making interaction with it as a programmer less than optimal. This and other issues, IMHO drives away the level of developers the project needs.

Rebuilding MODx on an O/RM using MVC-derived design patterns and a more consistent pattern of API’s that will be easier to remember, was ultimately my vision to attract higher-quality core and add-on developers to the project, though there are certainly a whole list of other benefits to doing this that I’ll spare you for now. I believe once this rewrite is stable and ready for release (including an SDK release targeted at 3rd-party add-on developers), we’ll be able to realize that vision. Until then I’ve been urging patience in targeting the market-at-large until we do have this new foundation in place and build a stronger team of committers, and I will continue to because, pardon the cliché, good things come to those who wait (OR <enter your own cliché here>).

Quote from: Sulman at Jan 27, 2008, 07:19 PM

Money is obviously the thing that every project needs, but is there any place where we can post a kind of "volunteer" listing for people that want to test their skills and contribute to a great project?

I have a year and half left before I get on the state bar...if this project stays alive, as I know it will, you guys better get ready for a big donation from a lawyer on the east coast...lol. Don’t hold your breath, but I just wish I could give a million dollars to this thing and have it take off! It deserves the best.

Volunteers and contributions are always welcome. MODx is a meritocracy and we recognize quality contributions in all their forms, often recruiting committers from the community, but we can ALWAYS use more help, collaboration, and dialog on the developer side of the house. We’re working on plans to make code contributions much easier for anyone that knows how to make an svn diff (i.e. team code reviews on user-submitted patches attached to tickets), but I encourage anyone with interest in becoming a core or just an early-adopting add-on developer to contact me regarding how they feel they can best contribute.

There’s just a lot that goes into sustaining MODx, not to mention trying to develop a thriving developer culture around it. But I trust both the principles MODx is based on and the growing community that surrounds it are solid enough that we’ll be around for a long time to come. Looking forward to those lawyer-size donations...

I wanted to follow-up briefly since I stirred up the pot ~1 month ago.

We’ve not disappeared. A small team has been hard at work wrestling 0.9.6 into shape for our immediate goals in this time. We’re nearing completion on the short term project and I wanted to let you know you’ll find us in March plugging away with you in the trenches on 0.9.7 and related modules. I expect to allocate 3 developers over a period of some months to contribute our humble help toward getting the next version done and enhanced. Personally, I’ll be more involved from a management perspective and am happy to interface with you in that way.

Thanks for your continued transparency, patience, diligence, and hard work. I and we look forward to helping out.

SeanPH, I think you’ll find contributing on the 097 front much more straightforward and transparent. We’ve recently completed a full-stack deployment from Atlassian – JIRA, Crowd, Confluence, Crucible – and I can say those guys make killer tools to make collaboration easy. More publicly on that soon.

I’ve passed the word around. Thanks. Interestingly, I’ve tapped a 4th resource whose focus is on UI. While the time commitment for this person will not be as intensive, I do hope the minor contributions will be received.

Y’know, this is going to be fun!