Ok, I have gone ahead and setup a test ikiwiki[1] instance, running reachable at [2]. I have used ikiwiki privately and for the nvda community addons website, and it can be used both as a wiki for documentation and a simple and accessible bug tracker. Best of all is that for those that prefer the command line (including me) it is just markdown files in a directory in our vcs. I have currently placed it in a separate branch so that it can be eliminated easely if we chose to go with something else. It allows everyone else using the web to log in using a ton of authentication services, so people don't have to register to create enhancement requests, bugs or add to the wiki. Also no need to solve any graphical or sound captcha. When anything is edited or added, it is automatically committed to the svn, so that no one is forced to go online to action anything. We can lock pages that should not be edited, to allow only admins to edit those. On the other hand if you edit the files in svn and commit, they should come live on the website. learning markdown is straightforward and is probably as close to raw text as we could get. It is very configurable, and our team of nvda translators and addon contributors seem to love it. Ikiwiki is also used for a lot of software and non-software projects, some of wich are listed in [1]. This is just another possible solution to evaluate before deciding on what might be most suitable. After creating the original configuration file, there are no databases or anything else to administrate, everything comes with the repository. So mirroring or moving servers is extremely simple. There is only one additional configuration file that I haven't committed to the svn yet. Markdown can be converted to docbook texinfo or many other formats using pandoc amongst other things. This solution solves our two recent discussions, with hopefully maximum accessibility. At the moment it will commit to the testwiki using my svn authentication, we probably need to create a separate account for web edits. I appologize for the commit mail this will cause while people test. comments welcome. [1]: http://ikiwiki.info [2]: http://liblouis.mesarhameed.info thanks, Mesar On Wed 16/10/13,09:05, John J. Boyer wrote: > As I said, a simple web form would be acceptable. No captchas! no > Javascript. Combo boxes aren't necessary. they can be replaced with a > series of radio buttons, with a select button at the end. I've done this > in php. A good example of a simple website is www.freelists.org . It > even works better in lynx than in elinks or IE. www.bookshare.org is > also a good example, although it has become rather cluttered. O > > > John > > On Wed, Oct 16, 2013 at 10:03:40AM +0200, Bert Frees wrote: > > No I don't think opening an issue by email is supported out of the box, > > although the Github API would allow it. For changing the status it's > > probably the same story. > > > > > > 2013/10/15 Michael Whapples <mwhapples@xxxxxxx> > > > > > This is what I was thinking of. > > > > > > I did not know about github allowing reply by email. Does it allow opening > > > a issue by email and changing the status of the report by email? > > > > > > While it would require hosting it I know that a system like roundup offers > > > all that. > > > > > > As John said though a simple web interface should be just as acceptable > > > and I would imagine it would be easier to find a hosted solution with a > > > simple web interface. However there does seem to be a trend for web > > > developers to complicate the interface for no apparent reason, other than > > > to show how much javascript/ajax/other web technology they can use. > > > > > > Michael Whapples > > > On 15/10/2013 21:08, Bert Frees wrote: > > > > > > I'm not saying "move to Github", but maybe there is an issue tracker out > > > there that has the same feature, in which case the accessiblity of the web > > > interface is not so crucial. > > > > > > On 15 Oct 2013, at 22:06, Bert Frees wrote: > > > > > > For what it's worth (and I haven't been following the discussion very > > > closely, so maybe someone mentioned this before): the Github issue tracker > > > has an "email reply support" feature[1], which basically means that you > > > can > > > follow and participate in conversations both with email and on the Github > > > website. > > > > > > [1] https://github.com/blog/811-reply-to-comments-from-email > > > > > > > > > > > -- > John J. Boyer; President, Chief Software Developer > Abilitiessoft, Inc. > http://www.abilitiessoft.com > Madison, Wisconsin USA > Developing software for people with disabilities > > For a description of the software, to download it and links to > project pages go to http://www.abilitiessoft.com
Attachment:
signature.asc
Description: Digital signature
