comments inline...
1) should we drop the standard reports from the maven site?
I would agree with that 'new brand of puppy chow' version of this question...I would keep these generating though to a 'old style' link until something better is all hammered out and in place..
2) JIRA & documentation Can anyone explain what the documentation version is for?
my bet is on documentation containing differences for older version of software still in use, api changes and documents detailing those kinda differences...
What do others think about merging the documentation categories for now, since we seem to agree this isn't the right breakdown of docs? (I saw a couple of dupes when I surfed across categories, but none within a single one). This gives a more managable task list.
+1
3) What is the role of the wiki? Wendy made some very good points about the accessibility of the wiki for getting doc contributions, which I think is worth exploring, especially since we can automatically bring it into the site. However, it comes with the downside that it can be less thoroughly reviewed and sometimes unstructured unless the person is really putting some extra effort in. So I think we have some alternatives: - use the wiki for everything, auto generate site - use the wiki for a specified section of the site, autogenerate (and perhaps mark as being contributed) - use the wiki as a holding area for new doc contributions I'd go with a combo of the last 2. I think the cookbooks section should have 2 parts - an apt/etc part and a contributed part autogenerated from the wiki using Wendy's proposal (and possibly doing the same per plugin) I'm in favour of using APT/local confluence markup for the main, verified part of the site (would want an easy way to convert confluence to APT, though). Thoughts on these?
I support the idea of a lot of the content being developed on the wiki and slurped into the main site simply. But this is mildly difficult since we do not want to lock all that process into confluence by any means...so what if we were to have a custom template or something in confluence and mapped a defined page x -> site x content mapping, and in that custom template or whatever try and validate that the content saved to the page adhered to a trimmed down set of tags that were simular to apt, or at least we spit out errors and failed the site generation in continuum if the pulling of text over from the confluence didn't match a set of info... basically anything that made the site really easy to make sure that anyone who was working with it followed strict guildlines format wise. would be really nice if we could pull a particular part of a wiki page into the site and then surrounding that there could be comments and whatnot and calls for improvement or what...say if the confluence page of 'Welcome Page' had a table in it with and id of "content" and in that table was the actual test for the page, and below that brett could add something along the lines of 'todo: spruce up the welcome text so that people know the difference between maven 1.x and latest release of maven. would be cooler still if there where multple tables (or whatever) with ids for content in different translations and we could manage that site content in different language through the same mechanism, all on the same page...and an aggregating page that shows pages of text that were missing translations for a particular language. being able to manage language translations through the wiki would make it easier for people to contribute along those lines then working with properties files and svn/patchs. though if you take into account language translations and whatnot then having the majority if not all of the website in the wiki starts making more sense, perhaps even going so far as to say the plugins could seed the wiki documentation effort automatically for english and then translations based on that being pulled down for website generation....depends on how fully you want to support internationalization. jesse -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
