Last modified: 2014-10-16 12:00:22 UTC
In order for the IssueTracker extension to be very useful, we need to implement an issue change history, like what Bugzilla has. How should we do this? Possibilities: 1) Create a new database table(s) for this (if so, how should it/they be structured?) 2) Use the existing page revision system Option #2 will probably require creating yet another namespace. https://www.mediawiki.org/wiki/Namespace_proliferation Also, the pages would need to be kept to a certain format in order to be parsed by IssueTracker. Any thoughts on the best way to proceed?
(In reply to comment #0) > Option #2 will probably require creating yet another namespace. > https://www.mediawiki.org/wiki/Namespace_proliferation Also I for one welcome our category overlords for sorting out every single thing. Now back to the proper question. You could probably store the details in the db somehow, then do a special page to grab the details (or to display a custom differ kinda like how AbuseFilter does) Or create a new namespace if you desire.
> I for one welcome our category overlords for sorting out every single thing. Aren't we (the wiki editors) the category overlords who do the categorization? :) > You could probably store the details in the db somehow, then do a special > page > to grab the details (or to display a custom differ kinda like how AbuseFilter > does) > > Or create a new namespace if you desire. Yeah, the "somehow" and the "if you desire" are what I'm trying to figure out -- which way is best, and what is desirable? Perhaps it's best to back up and ask what are the criteria that are important to people in deciding what's optimal? This bug is of potential relevance to [[mw:Requests_for_comment/Overthrow_Bugzilla]]. In order for IssueTracker (or anything else) to replace Bugzilla, we'd want to make sure it's designed in ways the community thinks are more awesome than Bugzilla's design. (Or maybe I should say "superior to" rather than "more awesome" since "awesomeness" has connotations of "o_O" to/from "O_o" conversion functionality. [[mw:Extension:Awesomeness]]) Otherwise, IssueTracker's use will be restricted to third-party sites, which will tend to make it less useful and deprioritize development work on it.
I would really like to see this extension improved. I've started working on fixing some of the more obvious issues, but it will need some extensive planning. Speaking from third party use, even core uses, some of the real wants I would like to see: 1. Better page integration. Why limit this as a stand alone system for just software or a whatever the project being tracked. Wiki pages have bugs too. Pages have issues such as incomplete, incorrect info, new edits and needs copyediting, etc. Link on a page to report a page with issues. Gives a better all in one location for admins and editors to view pages with issues, recent, old, priority. Preload a title in the tracker, Issue - Page Foo or something similar. This saves steps to, edit a page, add a template with text of issue, save page. 2. If a page has an issue, transclude the summary of the issue at the end or beginning of the page. Unassigned, assigned, whatever can bee added too. 3. Editor, text, WYSIWYG or WikiEd, then better wiki text parsing. Link outs to pages using wiki text. I did improve the vanilla editor to use TinyMCE when editing or adding an issue. Which makes it easier to insert links/images, create lists, etc. Not ideal, but better than a plain text box. 4. Permissions, they work somewhat, but the "assigned to" dropdown is not functional even with all the hacks saying it should work. The speciallistusers is not filtering by groups so you get a list of all users and can assign tracker items to any of them. Basically it was missing the $par for a group(s) of users to sort by and a check to see if they have permission to be assigned an item. Anyway, some thoughts to get started. I have a repo on GitHub, is there on for V1.1 yet?
I think the last activity was Gerrit change #91565, change I3fe59ca723e263bf923a926db27f1907b920dedd . I was leaving it as a project for an Inclumedia intern, but he flaked out. Then the organization whose wiki was going to be one of the first use cases I had in mind had a change of focus and decided they weren't going to continue supporting the wiki, and might shut it down. In short, whoever wants to work on it can, because it's no longer a high priority for me (although it certainly would be nice). Those four items above, you might want to submit as separate bugs, and maybe there will be one tracking bug that depends on them. If you want to coordinate work on it, then forking it to your own GitHub repo might be the fastest way to make progress, because then you can control the code review process. I wonder if any consideration was ever given to having +2s in Gerrit for individual extensions? The direct-push option is kinda like that, but I'm not sure if it gives the lead developer for that extension the same level of flexibility in granting push access to other developers as a separate Github repository does.
(In reply to comment #4) > I wonder if any consideration was ever given to having +2s in Gerrit for > individual extensions? That's possible and in fact done sometimes, I have no specific examples at hand, but in general check out [[mw:Gerrit/Project ownership/Archive]].
