So ... I'm seeing the comments fly around that replacing Moin Moin is the solution to solving our Wiki woes. For your consideration, I submit the following details. Thus we can all possess the same set of facts to work from. I'm not arguing for or against a tooling change. I just don't want Fedora Documentation to end up in a worse position. :) 1. Because of the long-standing Python bias of the Fedora Project, and the fact that Moin Moin is a popular and active Python-based wiki, Fedora Docs has long accepted this tool and adapted tools and practices to fit. Changing out this wiki engine is more than a technical exercise, and it affects content creation across the Project in the same way that replacing the buildsystem did for packaging. * Wiki formatting that can convert to DocBook -- processes * Wiki to DocBook conversions -- two GSoC projects; small tooling; processes * Release note creation process has small ties to Moin Moin way of doing things * Other WikiEditing processes that are tied to Moin Moin way of doing things 2. We have committed two Summer of Code internships to improving facets of Moin Moin for Fedora Docs, all this work happening upstream. However, this work has not been picked up entirely in the upstream tree, so hasn't made it into any releases. We have been suffering from not having a Python coder who can maintain the Moin Moin DocBook XML code. If we replace Moin Moin with another wiki, can we be guaranteed of Fedora Infrastructure support to replace those toolings? And do that in whatever language the replacement is written in? * Granted, some wiki communities are very active, so we might be able to grow a group of contributors around a useful plugin or two, where maybe we aren't seeing that in Moin Moin I guess the bottom line is around the challenges we've had in not being able to get code in the upstream, or having enough knowledge of the upstream to know when it is safe or proper to run the beta of the next release. I'd rather see Fedora Infrastructure or Websites commit to being involved more in the upstream, and fixing our problems there. If you decide that switching upstreams would do that, I reckon we'll need to get a deep requirements doc out of Fedora Documentation. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
