Various issues with dev.tw.o as I (lbmaian) see it:
Bug/wish searching
If you compare to Mozilla's bugzilla system (or other mature bug trackers like Trac), dev.tw.o's system leaves a lot to be desired.
There should be a single interface from which to search bugs. Not 3 separate ways as it is right now. In fact, the keyword list on the bottom-right is redundant since you can do the same thing with the filter interface. Ditto with the multiple links like "All Feature Requests" on the left menu.
I agree to get rid of "All *" links but I want to keep long list in plain site. This is consistent with doc and showcases what Tiki does. I would be ok with a scrolling window which shows only part of it but makes it very easy/clear to access full list.
- (ricks99) Maybe simply use PHP/CSS menus instead? My biggest issue is that there are more than 65 visibile menu options on the home page. IMHO way too many.
You should be able to query on more things besides "report type", "version", "feature", and "related project". What about narrowing down "date created" or "date last modified" or "author" or "priority" or any other field?
I agree and I tried to add "user selector" but it's not coded. About dates & priority, AFAIK, there is no dynamic filter for before date X or higher than priority Y. So for now, the way to do it is to sort the result of your search.
I've already mentioned Bugzilla and Trac, both of which have good bug querying capabilities, so we should copy them to a certain extent.
I (ricks99) would like to see 2 prominent links (even if they link to the same tracker):
- Log a bug (i.e., you found something that doesn't work correctly)
- Request a feature (i.e., you want Tiki to do something that it currently does not).
I have seen too many posts in forums or IRC by folks who were unable to request an enhancement.
Bug/wish entry and comments
I could not find a way to browse the latest comments other than the module to the right that only lists that last 5 comments. Bug comments are extremely important and should be much more prominent.
There is tiki-list_comments.php but it's not visible to anonymous and it doesn't work for tracker item comments (only wiki & blog)
The page for bug/wish entry is currently divided into 3 tabs (not including the edit "tab"). Since I consider comment and file attachments to be just as important as the bug description itself, it should all be collapsed into a single tab-less page, not requiring the user to have to click on the "Comment" tab just to view comments.
+1 I tried turning off feature_tabs and it's a disaster. We don't want tabs for coments and attachments, but we do want an edit tab. So this needs to be reworked somehow.
I find that most bugs have few comments. I like the Mozilla development process, where much discussion of how to fix/address the bug is done within the bug tracker, and most commits to svn are accompanied by a comment blurb briefly announcing/explaining the fix. In the Tikiwiki world, we have wiki pages, so we can supplement certain bugs/feature requests with more detailed wiki pages - just make sure the two are linked and consistent.
+1 and that related bugs/feature requests are linked between each other.
The priority field is also confusing - who determines what the priority should be? Only those familiar with the development process would know what the proper priority should be. With 10 possible values, it's impossible for a newbie to know the proper procedures.
Menus and overall UI of site
I don't know where to start with this. The overall feel that I get of the site is "cluttered". It's like it's trying to include everything but the kitchen sink yet failing even that. Some menu/modules are just redundant. As a dev.tw.o newbie, I was overwhelmed and confused.
The front page should be as simple as possible, containing high-level links and content that's deemed important to newbies or people just wondering about the state of development. That means far fewer modules on the front page, fewer links in the menus, information on the latest development (e.g. Tiki3) and where to get the latest alpha/beta/whatever release should have been prominent. Some of this content doesn't have to be on dev.tw.o - you can link to info.tw.o or doc.tw.o as needed.
Tikiwiki has a structure feature - use it! You can hide many of the less important links deeper within the structure and improve the organization of the site.
There should also be prominent links back to tikiwiki.org, info.tikiwiki.org, and doc.tikiwiki.org.
Everyone says and agrees that there should be less things. However, every time it comes time for people to do it, nothing happens. I hope someone will prove me wrong this time. 😊
alias
Various issues with dev.tw.o as I (lbmaian) see it:
!Bug/wish searching
If you compare to Mozilla's [http://bugzilla.mozilla.org|bugzilla] system (or other mature bug trackers like [http://http://trac.edgewall.org|Trac]), dev.tw.o's system leaves a lot to be desired.
There should be a single interface from which to search bugs. Not 3 separate ways as it is right now. In fact, the keyword list on the bottom-right is redundant since you can do the same thing with the filter interface. Ditto with the multiple links like "All Feature Requests" on the left menu.
{QUOTE(replyto="marclaporte")}I agree to get rid of "All *" links but I want to keep long list in plain site. This is consistent with doc and showcases what Tiki does. I would be ok with a scrolling window which shows only part of it but makes it very easy/clear to access full list.{QUOTE}
*(ricks99) Maybe simply use PHP/CSS menus instead? My biggest issue is that there are more than 65 ''__visibile__'' menu options on the home page. IMHO ''way'' too many.
You should be able to query on more things besides "report type", "version", "feature", and "related project". What about narrowing down "date created" or "date last modified" or "author" or "priority" or any other field?
{QUOTE(replyto="marclaporte")}I agree and I tried to add "user selector" but it's not coded. About dates & priority, AFAIK, there is no dynamic filter for before date X or higher than priority Y. So for now, the way to do it is to sort the result of your search.{QUOTE}
I've already mentioned Bugzilla and Trac, both of which have good bug querying capabilities, so we should copy them to a certain extent.
{QUOTE(replyto="marclaporte")}agreed and lessons learned should make their way to: http://profiles.tikiwiki.org/Bug_Tracker{QUOTE}
I (ricks99) would like to see 2 prominent links (even if they link to the same tracker):
*Log a bug (i.e., you found something that doesn't work correctly)
*Request a feature (i.e., you want Tiki to do something that it currently does not).
I have seen too many posts in forums or IRC by folks who were unable to request an enhancement.
!Bug/wish entry and comments
I could not find a way to browse the latest comments other than the module to the right that only lists that last 5 comments. Bug comments are extremely important and should be much more prominent.
{QUOTE(replyto="marclaporte")}There is tiki-list_comments.php but it's not visible to anonymous and it doesn't work for tracker item comments (only wiki & blog){QUOTE}
The page for bug/wish entry is currently divided into 3 tabs (not including the edit "tab"). Since I consider comment and file attachments to be just as important as the bug description itself, it should all be collapsed into a single tab-less page, not requiring the user to have to click on the "Comment" tab just to view comments.
{QUOTE(replyto="marclaporte")}+1 I tried turning off feature_tabs and it's a disaster. We don't want tabs for coments and attachments, but we do want an edit tab. So this needs to be reworked somehow.{QUOTE}
I find that most bugs have few comments. I like the Mozilla development process, where much discussion of how to fix/address the bug is done within the bug tracker, and most commits to svn are accompanied by a comment blurb briefly announcing/explaining the fix. In the Tikiwiki world, we have wiki pages, so we can supplement certain bugs/feature requests with more detailed wiki pages - just make sure the two are linked and consistent.
{QUOTE(replyto="marclaporte")}+1 and that related bugs/feature requests are linked between each other.{QUOTE}
The priority field is also confusing - who determines what the priority should be? Only those familiar with the development process would know what the proper priority should be. With 10 possible values, it's impossible for a newbie to know the proper procedures.
{QUOTE(replyto="marclaporte")}Please see and improve/comment ((Ease Importance Priority)){QUOTE}
!Menus and overall UI of site
I don't know where to start with this. The overall feel that I get of the site is "cluttered". It's like it's trying to include everything but the kitchen sink yet failing even that. Some menu/modules are just redundant. As a dev.tw.o newbie, I was overwhelmed and confused.
The front page should be as simple as possible, containing high-level links and content that's deemed important to newbies or people just wondering about the state of development. That means far fewer modules on the front page, fewer links in the menus, information on the latest development (e.g. ((Tiki3))) and where to get the latest alpha/beta/whatever release should have been prominent. Some of this content doesn't have to be on dev.tw.o - you can link to info.tw.o or doc.tw.o as needed.
Tikiwiki has a structure feature - use it! You can hide many of the less important links deeper within the structure and improve the organization of the site.
There should also be prominent links back to tikiwiki.org, info.tikiwiki.org, and doc.tikiwiki.org.
{QUOTE(replyto="marclaporte")}Everyone says and agrees that there should be less things. However, every time it comes time for people to do it, nothing happens. I hope someone will prove me wrong this time. :-){QUOTE}
-=alias=-
* (alias(DevTwoRevamp))