Hello!
> Have you seen the toc I've written?
Thanks for the re-port, because I remember glacing at it, but I could
not find it again.
> As for the two groups of people I agree. I've created a TOC because
> I've not yet found any central document which is focussed on the first
> part of users. There are some HOWTO's some tutorials and they all
> contain info concerning both groups but are more developer centric.
>
> Have you seen the TOC I've created? Any suggestion?
The TOC is really good, here are a couple more of ideas on how to have a
bigger impact with the documentation:
* Focus on Mono-specific bits first (or things that have emerged
in some way or other from Mono), then on generic .NET
components.
Rationale: there are plenty of books, tutorials, quickstarts,
and training courses for the generic components of .NET
For example, I would leave a C# tutorial out, because there are many of
those. It can still be done in the future, but we would not be giving
enough attention to the unique elements of Mono (what is likely the
information that people will be looking for).
Many of the Mono-born class libraries can be used in .NET and in Rotor
[1]
A few technologies that would be useful to document as part of this:
* The various database providers.
The System.Data hackers from Mono have created plenty of new
providers that are useful both to Mono and .NET, it would be
nice to have those new features documented.
* Developing applications with Gtk#.
Gtk# is something that does not exist in the Windows world, so
its a great candidate to document.
* API documentation for new Mono-born assemblies.
* Debugging with the Mono debugger.
* Using Mono to develop Unix applications.
Focusing on the development of applications for Unix using
Mono, which is a new universe for developers coming with a
Windows background.
* Contribution HOWTO: we do have quite a few documents on
contributions, but we should start to unify them.
* The various tools used during the build process for Mono
developers, tricks for programmers.
* Deployment issues, integration with Makefiles
(automake/autoconf/nant).
* Using the debugging interfaces to extract symbolic information
from programs at runtime.
[1] in fact, in the future, we should make it part of the "distribution"
process to ship packages that are immediately reusable in Windows,
without installing Mono, for the benefit of the Windows .NET
developers. But that should be discussed elsewhere.
_______________________________________________
Mono-docs-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-docs-list
