project
project summary freshmeat entry development infos mailing list WebInstaller database tools ChangeLog
page plugins
ProtectedEmail PowerSearch README README.config README.plugins README.fragments ProtectedMode INTERNALS WordIndex AboutPlugins PhpInfo OrphanedPages ListOfPluginHooks RSS RecentChanges PageIndex NewestPages SearchPages MostVisitedPages MostOftenChangedPages UpdatedPages
usage hint
Hint: You want to bookmark RecentChanges - really!
-- discussions that took place on and about the BugReports page
self choosen bug numers?
MarioSalzer: I refused to use the sf.net bug tracker, because the sf.net interfaces are to overloaded (sf ads layout everywhere) and annoying to me (w3m/lynx user). But should we use bug numbers for reference and archival use?
Instead of using a bug tracking software, we could simply invent the numbers ourselves (BUG#0304, WISH#5002) - not 100% clash safe, but at least a possibility. Eventually I could also write a bug report <form> especially for this page; seems easy.
Andy: Why don't we use aview_posts for this? We can enable it but not add it to the 'view' controls but instead reference it as a link (addpost/BugReports) only on this page. I'll extend it to let us hide closed bugs and eventually to move them to another page as we do now.
milky: The <form> already seems to work (that probably looks awful in Mozilla?), but does also not trigger the notify: plugin (like all workarounds). But I think that's only a matter of tighter integration...
Andy: It looks fine in Mozilla, but can we add a way to indicate that the bug exists in the current deployment to http://erfurtwiki.sourceforge.net ?