Robert, After thinking about this a bit more, I would suggest the following approach. (and you can document this on the how to contribute page if you would like)
Basically, site changes really fall into three categories: (and code changes somewhat do as well) 1) Purely technical - if technical information on the site is missing, out of date, or just plain wrong, it definitely needs to be fixed. I would strongly encourage folks to just make these changes as they see them. 2) Purely "look and feel" - on the opposite end of the spectrum is the look and feel things like the layouts, colors, navigation bars, etc.... In the code, this would include variable/method ordering, pom layouts, etc... There may be a reason why these things are the way they are and I would definitely suggest sending a note to dev@ with a proposal first to find out the "why". 3) In the middle of those two are the "purely informational" changes. The list of people, the links to articles, faq entries, how to contribute page, etc... This is kind of the "gray area". My suggestion for these is to think about the changes a bit and determine if the changes would require long term commitment to maintain or not. If not, go for it. Worst case, we complain and revert. :-) If it would require long term maintenance, definitely send a proposal first. When submitting patches to code, the other thing to think about is to definitely NOT mix too much into a patch. Smaller, more focused, patches are much easier to review. If something is wrong, much easier to revert as well. Mixing "look and feel" changes with "technical" changes is definitely problematic as the technical changes usually have more immediate value and would generally foster less objections and discussions. Hope this helps! Dan On Thursday 11 November 2010 4:28:01 pm Daniel Kulp wrote: > On Thursday 11 November 2010 11:20:54 am Robert Liguori wrote: > > Glen, Benson, and Apache CXF team, > > > > Glen's comment: "One should also analyze the opportunity cost of making > > the command line > > options looking the same as the GNU conventions compared to adding > > additional functionality to CXF,..." > > Robert's Response: The definitions of the command line options are > > different in at least three different places. Some of the inline usage > > definitions don't even match what the tool actually does. For the most > > extreme example, the usage for "idl2wsdl", starts out with "idltowsdl"; > > just do a > > "idl2wsdl -help" to see for yourself. "Cleanup" was my intent of the > > issue raised, meeting conventions in the process is considered a "best > > practice" and would be nice to the end-user community if achieved. > > OK. THESE types of things definitely are bugs and need to be fixed. > Patches for that would be great. :-) > > > Glen's comment: "... a similar issue to your earlier desire to have the > > CXF website be reformatted to look like Camel, ServiceMix, and > > ActiveMQ's." Robert's Response: It was my general feeling that ASF > > projects should be branded in a similar fashion. However, it's been > > made to clear to me by several people at ASF that forcing branding does > > not work well with open-source. > > Right. HOWEVER, the Apache Brand Management team did recently publish some > requirements for how are site uses branding. See: > > http://www.apache.org/foundation/marks/pmcs > > All of the Apache projects are expected to conform to that by end of Q1 > 2011. Thus, ANY enhancements or anything that would get us closer to that > would be great. (Honestly, I haven't read it yet so I don't even know how > far away we are) > > > Glen's comment: "So as you enhance the CXF documentation, please be sure > > that you're not > > giving CXF "puppies as presents", > > I love that phrase. I'm going to have to remember that. :-) > > > things that look cute but are of > > relatively limited benefit and need a lot of maintenance afterwards to > > remain cute. " > > Robert's Response: I'm definitely not on the same page as the CXF team. > > It was a nice stay. If any of my other updates seem that they do more > > harm than good, please revert the web pages back to old instances. I'm > > not going to fall anything else back, as I feel that has been value in my > > improvements to the web-pages content. > > Basically, the documentation on the site needs to be correct. I'm > definitely not arguing about anything about that. If you see something > wrong, by all means, please fix it. > > However, for things that change relatively rapidly (such as dependencies > and versions and such), if they don't need to be on the web site, it's > usually best to not put it there as it's likely to get completely out of > date. As release manager, I know how much time is spent making sure the > legal files and such in the distribution are correct. I really would > prefer not having even more places to update. > > Anyway, I definitely encourage you to keep going. I'd LOVE to see you > start submitting patches for some of the things and work toward becomming > a committer. > > Dan > > > To wrap things up on my side, I'll look at the issues I have opened and > > will try to align them with the general open-source philosophy. > > > > Take care, > > Robert -- Daniel Kulp [email protected] http://dankulp.com/blog
