I'm late in on this one... I think as you have already dropped the "Garden" brand it should be dropped from the codebase. I like what @bean suggested, and rename the Vanilla application to Discussions... Adds clarity IMO!
I also wouldnt worry too much about breaking changes at the moment - its not even had an "official" release yet so I guess people expect it.
I agree with calling the framework Vanilla, but given that, surely this app should be called "Forums" and not "discussions". What are your URLs? vanillaforums.org and vanillaforums.com? Looks to me you'd need to change those to vanilladiscussions.org/.com - of course, if you are happy to change the URLs, then go ahead and call the app "Discussions"
Also, even if you call it Discussions, you know people will call it "forum" anyway...
@fredwu - Any class that implements Gdn_IPlugin uses underscores in method names as special characters that help the plugin manager identify when and how to execute that method. It's not a case of not following the standards, it is a case of the documentation not indentifying the exception to the rule. Thanks for noticing, though - I'll update the doc.
The whole reason for this discussion is to figure out inconsistencies and fix them. Vanilla 2 hasn't even been released yet, so if you find that things are incomplete (comments, documentation, even classes with @todo's), we are working on it. If you want to get involved and help out, please do!
Renaming the lussumo github account and the Garden repository might have a limited impact. It won't affect people who follow either the account or the repository; I don't think it will affect the forks*; people who track git://github.com/lussumo/Garden.git will just have to change a git setting entry:
cd /path/to/garden/repository/ git remote set-url origin git://github.com/vanillaforums/vanilla.git
or for repositories which have "origin" pointing to a fork, if the mainline repository was called "mainline", it would be:
garden just makes things confusing, vanilla as the framework, Apps as conversations, App Discussions, and im hoping for APP embeding media into discussions, but yeh anyway, well done for all the hard work.
I am firmly of that stance: Vanilla is a forum application. Call the framework what you will.
I don't understand how some reason that switching the names around would be *less* confusing. People everywhere know Vanilla to be forum software. How would changing its meaning be less confusing for the masses?
Garden has been marketed for some time now as being a framework. Heck, on the front page of the documentation it says, "What's growing in your garden?" (which is pretty catchy!)
I could comprehend changing the name of Garden, if you don't like it, since it's still in beta and has not been widely adopted. Perhaps spin "Garden" as having been the code name of the project.
It just doesn't make sense to change the meaning of a well-known piece of software.
"What's growing in your garden?" I love it! It sounds like decisions have already been made, but the Garden framework and Vanilla application made perfect sense to me. ;-) I've already played with the (name goes here) framework and it looks great. I'm really looking forward to the next releases.
Hi all, I'm new to the community and I would like to share my opinion about Vanilla with you.
When I first read the documentation for the first time it was *unclear* what Garden was, but reading carefully throught the entire documentation helped me to figure out. Naming the backing framework Garden is not a bad idea, also having Vanilla built on top of Garden is not an issue, but it should documented better.
I expected to find a *naming convention* discussion here, not a branding one :P
The big issue imho is with the APIs. Garden is certainly a good piece of software because it *does* what is was meant to do, and it does it well, but this can't mitigate the intrinsic flaws of Garden code: 1. There are no Unit Tests (that's not a major issue, although it would be a good indicator of robustness of the code) 2. There are public fields scattered all over (it's a cardinal sin :P) 3. The average cyclomatic complexity for each method is **5.04** (in a scale from 0 to 10. That's too much.)
I would never rely on code that is not well documented (docs and comments in code), unit tested, has object internal state exposed and has that much complexity (the higher the C. Complexity the higher are the number of bugs).
Hope to be helpful in some way, I really love this project. Keep rockin
PS: I used Sebastian Bergmann's PHP Lines Of Code on library/core/ folder to determine the cyclomatic complexity, here it is the output: http://pastebin.com/f56f099f5
Comments
I also wouldnt worry too much about breaking changes at the moment - its not even had an "official" release yet so I guess people expect it.
@bluecircle - dully noted and agreed.
Vanilla, vn_ -> Apps --> Discussions -> Conversations -> ?
Keep it "Vanilla" Mark!
Also, even if you call it Discussions, you know people will call it "forum" anyway...
I think the only thing here that would really confuse me, if I didn't know any better, was the difference between a discussion and a conversation.
I was really surprised to see files such as this:
http://github.com/lussumo/Garden/blob/master/applications/vanilla/settings/hooks.php
The function names used in this file, are in direct violation of the coding standards and practices you guys set yourselves:
http://vanillaforums.org/page/StandardsAndPractices
Not to mention some of the functions lack PHPDoc comments.
The whole reason for this discussion is to figure out inconsistencies and fix them. Vanilla 2 hasn't even been released yet, so if you find that things are incomplete (comments, documentation, even classes with @todo's), we are working on it. If you want to get involved and help out, please do!
Actually, yes, I do intend to get involved and help out.
I like Discussions as much as anything, but then again, I liked the Garden/Vanilla combo.
git remote set-url mainline git://github.com/vanillaforums/vanilla.gitThat's a small price.
About the prefix, it would be nice to have something similar for the JavaScript part, like: *Does someone know if renaming the mainline repository affect the name of the forks? I am guessing it doesn't
I don't understand how some reason that switching the names around would be *less* confusing. People everywhere know Vanilla to be forum software. How would changing its meaning be less confusing for the masses?
Garden has been marketed for some time now as being a framework. Heck, on the front page of the documentation it says, "What's growing in your garden?" (which is pretty catchy!)
I could comprehend changing the name of Garden, if you don't like it, since it's still in beta and has not been widely adopted. Perhaps spin "Garden" as having been the code name of the project.
It just doesn't make sense to change the meaning of a well-known piece of software.
I'm new to the community and I would like to share my opinion about Vanilla with you.
When I first read the documentation for the first time it was *unclear* what Garden was, but reading carefully throught the entire documentation helped me to figure out.
Naming the backing framework Garden is not a bad idea, also having Vanilla built on top of Garden is not an issue, but it should documented better.
I expected to find a *naming convention* discussion here, not a branding one :P
The big issue imho is with the APIs. Garden is certainly a good piece of software because it *does* what is was meant to do, and it does it well, but this can't mitigate the intrinsic flaws of Garden code:
1. There are no Unit Tests (that's not a major issue, although it would be a good indicator of robustness of the code)
2. There are public fields scattered all over (it's a cardinal sin :P)
3. The average cyclomatic complexity for each method is **5.04** (in a scale from 0 to 10. That's too much.)
I would never rely on code that is not well documented (docs and comments in code), unit tested, has object internal state exposed and has that much complexity (the higher the C. Complexity the higher are the number of bugs).
Hope to be helpful in some way, I really love this project.
Keep rockin
PS: I used Sebastian Bergmann's PHP Lines Of Code on library/core/ folder to determine the cyclomatic complexity, here it is the output: http://pastebin.com/f56f099f5