atm. we are including:
plone.api
plone.schemaeditor
plone.dexterity
plone.app.contentrules
plone.app.contentrules
plone.app.dexterity
plone.app.multilingual
plone.app.portlets
plone.app.robotframework
plone.app.testing
plone.app.theming
plone.app.viewletmanager
plone.app.workflow
ploneorg.admin - this will not be done
Products.CMFEditions
Products.DCWorkflow
Products.GenericSetup
Products.ResourceRegistries
Products.TinyMCE
sphinxcontrib.contributors
tutorials.todoapp

is this still up 2 date information ? do we want to include others like PloneFormGen ?

Hi, I just wondered, if we also want an installation-section in the docs, where we could provide and collect reliable recipes to set up dev-builds by using virtualenv, e.g.? If you think that would be helpful, I'd like to start to write it, just would need assistance on how to create a new chapter, then.

we have to move Deliverance docs, looks like some ppl are using it, does it have to go into the Plone 3 or Plone 4 branch ?

I'd like to recommend that headings in the documentation use Title case with words like "to" and "a" remaining common, proper nouns like "Plone" should ALWAYS be captilized.

For example:

How to Capitalize Plone Documentation Headings

as opposed to sentence case:

How to capitalize Plone documentation headings

Capitalize the first word of the title, the last word of the title, and all “principal” words (that’s essentially the same parts of speech I just listed—nouns, verbs and so on), and all words longer than three letters. That is the style currently recommended by the Associated Press (2). (You can see one of the major differences between Chicago and AP style is that in Chicago style, a long preposition such as “between” would not usually be capitalized, whereas in AP style, it would.) - See more at: http://www.quickanddirtytips.com/education/grammar/capitalizing-titles#sthash.8flAJY7P.dpuf

I'm happy to starting doing this, assuming it is endorsed (plus I owe some documentation work from the last sprint :) ).

On https://github.com/plone/documentation/blob/master/about/documentation_styleguide_addons.rst we recommend "So, if you create a README.rst, do it in the /docs/source directory, and make a symlink to it from the root of your repository.".

On collective/collective.recipe.filestorage#3 (comment) @davisagli notes that symlinks will probably be a problem on Windows.

What's our position on that?

in my opinion, the xdv and deliverance docs should be removed. xdv refers to the previous incarnation of diazo, and deliverance has been replaced by diazo.

http://docs.plone.org/adapt-and-extend/theming/deliverance.html
http://docs.plone.org/adapt-and-extend/theming/templates_css/xdv.html

Add the documentation setup to jenkins, so that we catch issues early

http://plone.org/products/plone/releases/4.3.3

write the docs

write howto about that, include also stuff like:

Git workflow / branching model

It is important that you NEVER commit to master directly. Even for the smallest and most trivial fix. ALWAYS open a pull request and ask somebody else to merge your code. NEVER merge it yourself.

If you don't get feedback on your pull request in a day please come to #plone-framework and ping @garbas or @vangheem about it.

The main goal of this process is not to boss developers around and make their lives harder, but to bring greater stability to the development of mockup and to make releases smooth and predictable.
Pull request checklist

Checklist of things that every person accepting pull request should follow (or else @garbas will make you drink a Mongolian cocktail - I promise!).

The title and description of a pull request MUST be descriptive and need to reflect the changes in code. Please review, line by line, and comment if the code change was not mentioned in the description of the pull request.

Copy the title of the pull request to the current ticket tracking changes for release under development. (example: https://github.com/plone/mockup/issues/250)

The full test suite (which runs the tests on saucelabs against real browsers) will only be triggered for the master branch and the pull requests. It is important that the tests pass before you merge it.

Please note that the Travis job sometimes hangs (for various reasons) and then you need to restart it.

Due to some bugs in Travis regarding reporting of the status, be sure to always check on https://travis-ci.org/plone/mockup/pull_requests that the tests really have passed.

It is important to never lower code coverage. Check coveralls to see that coverage hasn't dropped. It should be reported automatically once the tests pass.

Make sure that every new function (or bigger chunk of code) that is added to mockup is tested.

All commits need to be rebased on current master and squashed into one single commit. The commit's title (first line) and description (row 3 and below) should be identical to the pull request.

Once you've ensured that all the above is correct, go ahead and merge the pull request. Make sure you always use a polite tone and explain why this is needed by linking to this document.

change this to documentation, this is taken from: http://plone.github.io/mockup/dev/#contribute

On https://github.com/plone/documentation/blob/master/about/documentation_styleguide_addons.rst we recommend "So, if you create a README.rst, do it in the /docs/source directory, and make a symlink to it from the root of your repository.".

On collective/collective.recipe.filestorage#3 (comment) @davisagli notes that symlinks will probably be a problem on Windows.

What's our position on that?

On https://github.com/plone/documentation/blob/master/about/documentation_styleguide_addons.rst we recommend "So, if you create a README.rst, do it in the /docs/source directory, and make a symlink to it from the root of your repository.".

On collective/collective.recipe.filestorage#3 (comment) @davisagli notes that symlinks will probably be a problem on Windows.

What's our position on that?

use:
http://schacon.github.io/git/git-read-tree.html#_sparse_checkout

to fetch external resources

collective.transmogrifier has re-arranged their docs to be in a format we can integrate. Let's look at the mind-map, think, and determine a good place where they should go

for ex.:

• saltstack
• ansible
• puppet
• etc..etc..

note: all the examples should be done based on the unified installer

Include docs over handy tools, trips and tricks for starting developers, like search plugins, editor configs and testing applications

I just wrote this StackOverflow question: http://stackoverflow.com/questions/22760485/how-one-should-check-for-a-permission-in-plone

Which basically boils down to: from two different documentations in current developer.plone.org we get two different ways to check for a permission, which is the one that should be used?

So maybe it would be a good idea to create some small tips/recipes on how to do things and never ever let any documentation try to explain that, but instead refer to this tips/recipes.

This way we keep everything consistent and always easy to get up to date.

Make sure that all our docs about installation are based on our Unified Installer

after moving the content to the new setup, check index pages and links if there are not working fix it !

We do need documentation for Integrators

https://github.com/plone/documentation/blob/master/adapt-and-extend/basics.rst

do a fetch and add it there

• describe plip and add docs to this

I've run "make linkcheck", and a large number of links are broken. I've fixed a number of them already, prioritizing the end-user docs.

The list is in the repo, at https://github.com/plone/documentation/blob/master/broken-20140331.txt

for the moment: if you fix a broken link, update that file and push.

SSL/HTTPS

on kb old we have long and old example guide over apache with ssl on the current docs we have two short examples, we should check them and if necessary update them

review/merge this to docs.plone.org:

plone/plone.app.caching@1903be9

see as sphinx version: https://pythonhosted.org/plone.app.caching/

This ticker is related to: plone/Products.CMFPlone#170

extend currrent docs about plone.app.contenttypes
with best practices with reference link to dexterity

Explain how to deal with upgrades of a OS and Plone
What are the steps

How to setup core.dev and get involved into development on core.dev

https://github.com/plone/documentation/blob/master/develop/plone/content/history.rst#id2

include all docs about mockup/toolbar and so on, this goes together with:
plone/mockup#279

collective/tutorial.todoapp: index, list of modules, own searchbox not working, has GH warning
plone.api: has GH warning
plone.app.testing: index, list of modules, own searchbox not working
(beginning to suspect this is an artifact of sphinx defaults...)

How to turn off HTML filtering (a.k.a. "I want to embed stuff") needs to be documented. This is also a good candidate for our versioning, since it differs for the various plone versions. Also, link to http://glicksoftware.com/blog/disable-html-filtering

include plone.app.contenttypes

move them from old kb

We need to have docs about robot testing

http://plone.org/documentation/kb-old/how-to-create-a-sphinx-based-documentation-for-your-project

We should check what we should include from the old manual

Also we should explain better, what a README should include, like best practices

Move docs from rtd to here

On https://github.com/plone/documentation/blob/master/about/documentation_styleguide_addons.rst we recommend "So, if you create a README.rst, do it in the /docs/source directory, and make a symlink to it from the root of your repository.".

On collective/collective.recipe.filestorage#3 (comment) @davisagli notes that symlinks will probably be a problem on Windows.

What's our position on that?

do we want to keep preface ? maybe somewhere else ?

currently, there are diazo docs on these places:

http://docs.plone.org/external/diazo/docs/index.html
http://docs.plone.org/adapt-and-extend/theming/theme_product_with_diazo.html
http://docs.plone.org/adapt-and-extend/theming/templates_css/diazo.html
and
http://docs.plone.org/external/plone.app.theming/docs/index.html

these docs should better be combined instead seperated.

fetch external diazo docs and add them to theme

How is the docs.buildout working, how do we configured translations and robot image/video

we want to have a recipe with a default sphinx setup, folder structure and such stuff, like a for example a default site which fetches, git repo, about, author and so on from setup.py

http://plone.org/documentation/kb/manually-removing-local-persistent-utilities

Needs to be finished

At the moment there exists only an section with a copy of the oldstyle collections introduction for it.

How to create a working testing setup for development and how to use it, like travis, jenkins and so on