[Mono-dev] Mono.Addins in Monodoc

Mario Sopena Novales mario.sopena at gmail.com
Thu Dec 20 07:59:22 EST 2007


Hi,

On 19/12/2007, Miguel de Icaza <miguel at novell.com> wrote:
>
> > >         * Editing in the ECMA provider is hard, but Mike has a plan for
> > >           that.
> > Is there any doc or something we could review?
>
> No, we only spoke on the phone about it.
>
> The idea is that Mike wants to switch to use GtkTextView to render the
> documentation, and at the same time, this would allow us to implement
> editing very easily.
>
> Am not sure how you can block certain sections from being edited, but am
> sure it can be done.

I'm not sure this is a good idea because you will end up with two
paths to render the documentation: the GtkTextView and the Html
(because you will still maintain the web version). And I think the
GtkTextView approach is costly to develop and at the end you will not
get so much benefits from it.

Wouldn't it be better to go only web but improve it to being able to
edit/search/etc.. and do that also offline? This will left us only
with one frontend to worry about.


>
>
> > This is in some way (maybe not much, I dont have the numbers but just
> > an impression) affected by the fact that in monodoc is hard to see how
> > the contribution gets back to the contributor. The process is slow.
> > I mean, the user cannot install new documentation (only installing a
> > "new" monodoc and that is slow specially if it comes packaged in the
> > distro) and the process to review/approve/publish new doc is also
> > slow, making at the end that the contributor feels his contributions
> > gets lost in the limbo (well, at least, that was what I was told
> > several times). The way we have it now discourages contributions.
>
> Correct, there are many things that we could do to improve the pipeline
> for new documentation.   Some of those ideas are also required for the
> Web edition of Monodoc.
>
> Having a hammer does not mean that everything is a nail, and for the
> case of documentation updating we should not start with "We have
> Mono.Addins, now how do we do updates with it".
>
> Instead we should be thinking about creating the proper pipeline for
> documentation: what does it look like, what is the process, and then
> implement it.
>
> If the implementation would benefit from Mono.Addins, that is fine, but
> it should not be the driving force for it.
>
> Miguel
>



More information about the Mono-devel-list mailing list