I would prefer to keep discussion on-wiki, so that other people can see it and participate, if that's OK. I am aware of the very long thread recently in wikitch-l about too much face-to-face conversation, and not enough transparency and I don't want to exclude other contributors from the discussion. If there are specific things that would benefit from a Skype chat then I'm not totally against it, as long as it is transcribed, so if you feel a strong need then let me know. IRC is another alternative, of course, which would save having to do a transcription... ;-)
I understand your point that you are planning to start with small incremental changes. My worry would be that without a good overview of the project and what, in the long run, you intend to acheive for MW.org as a whole, it could end up being quite wasteful of effort. Make sure you aren't focussing on the climb before you've worked out whether you're on the right mountain!
The CSRF page is probably done 'right', and that highlights that there is probably no single generally-applicable solution. However if you look at it from the point of view of the three groups, the page is very definitely a developer focussed issue - i.e. "How, as a developer, should I code in order to mitigate the chances of CSRF?". It has a much smaller, secondary use for administrators - "What techniques does MW use to ensure my wiki is not vulnerable to CSRF attacks, and is there anything I, as an administrator, should be doing to further reduce this risk?". For the third group - wiki users - it has no relvance whatsoever.
Finally, in terms of the point you make about the help documentation, take a look at Project:PD help and Project:PD help/export. I envisage an MW plugin (or, ideally, core feature) where it can automatically download, install and keep up-to-date the Help: namespace of your local wiki, using whatever language(s) you choose.
I'm happy to keep things on-wiki or in other public text channels. Just let me know what works best for you. I suppose that my preference is a mix of LT discussions and IRC chats. LT lets us summarize and such, which IRC lets us short-circuit some kinds of potential misunderstandings.
I take your point about climbing the wrong mountain. At present, I'm focused on becoming a part of the community, improving the content of the docs, testing ideas from the draft plan and working with others to improve the draft. The metaphorical mountain-climbing will come later.
With the CSRF page, it is written for the primary audience - developers. It is relevant for wiki users only in that they may find their way to the page accidentally and should be able to figure out via the overview that it isn't a page for them. :)
Regarding the help docs, I can pros and cons to having a feature that pulls down the docs.
- wiki is populated with most recent docs (compared with bundled docs, which would likely only be updated once per release.)
- feature would disclose information by "w:Phoning home"
- multiple runs of the feature would need to deal with the situation where the docs are newer than the version of MW pulling the docs
- multiple runs of the feature should not overwrite local edits
With regards to having the help docs in the default install, I think we can do both solutions! The new installer is going to (soon) have the ability to (optionally) phone home. The original idea behind this was being able to get statistics on installs and upgrades.
It would be (fairly) trivial to add a post-install step called "Setup help documentation." You could have the option of pulling the documents directly from MediaWiki.org (ensured to be up-to-date), or use the dump we packaged with the install (possibly slightly outdated, was dumped at package time).
At upgrade time, we could offer to pull the updated docs from MW.org, or use the (possibly updated) dump.
As far as doing Help during post-install, there's a bit of info over at New-installer_issues#Features about some post-install processing we could do. But nothing's formal yet and that page is mostly a tracking page for outstanding issues.