On 4/25/07, Emmanuel Blot <[EMAIL PROTECTED]> wrote: > I would not like to disable most of the Trac powerful syntax in a > developer team that can be teached in a couple of minutes how to use > Trac wiki syntax, while I understand Waldermar's opinion which > considers Trac in a more open environment where Trac users may be > random users that really don't care about Wiki syntax and simply want > to report a bug, as with any lambda bug tracker.
Well, if you don't have direct face-to-face access to those developers it's really *very* difficult to teach everyone. You send out emails, but they sometimes get ignored because there are lots of other development discussions going on. Also, I didn't even think of the quickjump feature when I explained it to them. I didn't want to send them a long email to learn. That makes them more reluctant to switch to Trac (some of them wanted to stay with BugZilla). Then, slowly, Trac's quirks become apparent and our developers wonder why they can't search for a function name like SendData() in the search box, so they fail to find a related bug and time is wasted. Moreover, while you might expect the project devs to learn something you can't expect others to know that "!" disables quickjump. This will always lead to user mistakes. Regarding wiki syntax, please take a look at: http://dev.haiku-os.org/ticket/1167 We have *lots* of bug reports with tracebacks. Function names often get recognized as wiki words (I enabled ignore_missing_pages, so you can't see this). This makes tracebacks look very ugly. Also, nobody escapes newlines in those tracebacks, so I had to patch Trac to escape them in tickets. Another problem is that many tracebacks contain "__" sequences which are part of function names and Trac thinks these are commands to underline a function (as you can see, I haven't patched that). This is really annoying. You are not affected by this (partially because of Python), but this doesn't mean that other project (esp. big ones) don't have problems. I'm just reporting the usability flaws that we stumble upon, so Trac can be improved for other big, open projects like us. If you don't agree, well, fine, I'll continue to customize Trac to be easy to use for our bug reporters. The drawback is that others won't benefit of my patches. Currently, Trac is processing user input far too aggressively and strictly. Since you are all used to Trac and mostly have devs reporting bugs you might not agree with me, but I'd bet that other projects have the same problems with Trac. It becomes more difficult to switch from BugZilla if the wiki syntax breaks old BugZilla tickets after a migration and it's generally making Trac less useful if non-dev bug reporters can't naturally use Trac, but have to cope with its quirks. > IMHO Trac can be quite versatile and fits well in many different > environments and projects and I think that one way to reach this wide > audience is not to force one mode or another, but give the Trac > administrator/maintainer the final choice. What should the default settings be, then? Should they be defensive and as simple as possible, so everyone can naturally use it? Or should they be more strict where people know that they use wiki syntax? I think it's better to have a good base that works for everyone and then allow for customizing if every Trac user knows the syntax, etc. > Enabling too many configuration settings (not mentioning the setup > nightmare and potential support nightmare...) would also confuse the > end user who is used to Trac. 100% agreed. Bye, Waldemar Kornewald --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
