841973 - idea: mediawiki syntax front-end proxy for MDN (+ via firefox extension?)

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Editing, defect)

Description

[Jeff Hammel]

I friggin hate mediawiki syntax and hope it dies a quick but painful death.  That said, I've noticed that every single conversation about communication quickly turns into "Wah!  I can't do any documentation because i need mediawiki! I hate the GUI! I hate editing HTML! I give up on MDN!!!" Slight exaggerations aside, its fairly annoying, especially since if you're one of the thousands of people -- like me! -- that finds editing mediawiki syntax more annoying than editing raw HTML (ignoring entirely the implications on the backend store...its almost like people want the web replaced with mediawiki syntax o_O), then our "deal with it" means nothing compared to that received when I complain about wiki.m.o.

While my #1 preference would be for people that like mediawiki syntax to go to reeducation camps, and would love in some ideal world for the input/output to be selectable and tuner on an (expert) user-basis (e.g. markdown or ReST might be nice, for some things; I prefer ReST for all its deficiencies, not that it matters), that's a serious project in its own right.

However, I do think, if the time/resources/desire was there and was estimated to exceed the cost to mozilla caused by developers obstructing documentation because things aren't in the flavor that they prefer, that we could accomodate mediawiki syntax with absolute zero change to in-use codes.

I propose the following as an idea: some combination of proxy server and firefox extension that will present MDN HTML as mediawiki, present for editing, and transform back to HTML for posting.  Assuming MDN has a good API (I think the minimal API required to support this is trivial anyway), the basic workflow is the following. When you go to edit...

- the proxy fetches the MDN page; just the contents that is, not what is wrapped around stuff (that is, the stuff from the GUI when you view as HTML).  I'm guessing this already exists :)

- using some converter (there are many out there), the HTML is converted to mediawiki syntax.  This is doable because, in its infinite wisdom, mediawiki allows (whitelisted, but unimportant for our purposes) HTML in its markdown (IMHO, a mistake, but it serves my purpose here).  So even if you don't get all the page, hopefully it is good enough to silence the complainers. (This is one of the reasons that i'd do this sort of thing as an unofficial proxy vs anything having to do with kuma internally or even kuma branded.)

- (Given the above, even if we were to roll our own converter it wouldn't be the end of the world.)

- the person edits the mediawiki text.  They salivate.  For some reason unknown to me, it gives them great joy.

- then they post to the proxy.  The mediawiki text is converted to HTML (much easier than the reverse, though some nuance probably).

- the proxy posts the converted HTML to MDN.  Sheppy and I don't have to cry and everyone is happy.

- A firefox extension can be used to make all of this more transparent.  E.g. making the edit link do what you want, etc, instead of having to navigate between sites (there is auth to consider as well, which ideally just wouldn't be an issue and could totally be avoided with auth).

- So you might ask: why not do everything in a Firefox extension?  A valid point.  I wouldn't be inclined to go down that route as I like writing software for everyone.  While there is the api to get and post to MDN, everything else is a mediawiki proxy to HTML generically. I would not be opposed to a Firefox extension that used code that, say, was mutually used by node.js...but have never done that myself ;) (I mostly use python for web services and would so here if it were just me.)

Yes, its quite a big project and I post it as a "for your consideration".  TBH, if I was one of the mediawiki zealots, I would hope that I would write this damn thing instead of complaining about constantly.  Yes, I am proposing to write software that I would never want to use for a use-case I consider wrong(!).  But that's how it is.
 
I don't know how the uptake would be.  I don't know where it would be hosted.  I don't know much about such things.

I do, occasionally, write web services ;) And I'd be happy to help out if there is interest in this approach.  I'm not going to champion it if people feel it is the wrong approach. I do think if it were successful in getting uptake, it could at least get us out of the state of things we're in that even to mention the word "documentation" invokes "but mediawiki!".  Cuz, ya know, its so awesome :)  So I don't care about this software.  I do care about getting Mozilla to a state where we can have discussions where we can talk about documentation beyond just how not having mediawiki syntax makes life not worth living anymore.

Comment 1

[Eric Shepherd [:sheppy]]

I think this is a good idea, and it's something we've talked about in the past. But it's a pretty big project and not a priority for our regular dev team. However, I think we would be very supportive of someone taking it on!

Comment 2

[Jeff Hammel]

(In reply to Eric Shepherd [:sheppy] from comment #1)
> I think this is a good idea, and it's something we've talked about in the
> past. But it's a pretty big project and not a priority for our regular dev
> team. However, I think we would be very supportive of someone taking it on!

Yep, totally.  If it wasn't clear I was not advocating putting formal Mozilla time/resources on this, either of your team or myself, but am more than happy to somehow find extracurricular time to do so.

Comment 3

[Eric Shepherd [:sheppy]]

(In reply to Jeff Hammel [:jhammel] from comment #2)
> (In reply to Eric Shepherd [:sheppy] from comment #1)
> > I think this is a good idea, and it's something we've talked about in the
> > past. But it's a pretty big project and not a priority for our regular dev
> > team. However, I think we would be very supportive of someone taking it on!
> 
> Yep, totally.  If it wasn't clear I was not advocating putting formal
> Mozilla time/resources on this, either of your team or myself, but am more
> than happy to somehow find extracurricular time to do so.

That would be most excellent!

Comment 4

[John Karahalis [:openjck]]

Glad to see there is enthusiasm about this. Maybe we could get someone familiar with user experience to share some thoughts before we push this, since it is a pretty big feature and a significant departure from what we have now.

Comment 5

[Jeff Hammel]

(In reply to John Karahalis [:openjck] from comment #4)
> Glad to see there is enthusiasm about this. 

I am too! :)

> Maybe we could get someone
> familiar with user experience to share some thoughts before we push this,
> since it is a pretty big feature and a significant departure from what we
> have now.

That would be very valuable; while I am fairly knowledgeable wrt the backend development required, I do not know how to make sites that people actually like to use or are pretty ;)

While obviously this is in direct support of MDN and kuma, I look on this more as a separate project vs a feature. Encapsulation will allow the coding to be (ignoring REST API changes) completely separate, it will run on separate servers, the audience is different as is likely their use case, and if the worst happens, this (whatever codename we give it) can fail with zero impact on MDN.  Apologies if I'm being pedantic and being too literal about wording, but I think this is worth clarifying.

Comment 6

[Jeff Hammel]

After a bit of looking, it looks like pandoc is the best in town:

http://johnmacfarlane.net/pandoc/

I'm not a haskell fan or guru, but its a good language (better than, say, PHP) and if this gets this as far as I think it might, I think it'd be worth doing and potentially contributing upstream

Comment 7

[John Karahalis [:openjck]]

Do we want to revisit this idea in light of the following?

https://bugzilla.mozilla.org/show_bug.cgi?id=780227#c4

Comment 8

[Jeff Hammel]

I would love to advise and assist however possible.  I am very backlogged right now, but if the merit and potential worth is there, I figure that time could be made.

Comment 9

[Eric Shepherd [:sheppy]]

(In reply to John Karahalis [:openjck] from comment #7)
> Do we want to revisit this idea in light of the following?
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=780227#c4

I agree with James's opinion that supporting multiple markup formats for MDN content is not a good idea. However, if someone wants to investigate ways to help people that don't like WYSIWYG and aren't happy with HTML contribute, they should feel free. I just don't think we should use primary dev team resources on this issue.

Comment 10

[Jeff Hammel]

Agreed.  To reiterate, I'm not devoting Mozilla time or resources to this, but am happy to help get the ball rolling if there is interest or questions.  I think the concept is compelling, not just for MDN but for wikis in general (with different implementations or abstracting to a more general pattern).  Personally, I'd start with a minimal view with webob and pandoc and see where that lead