From: Oskar B. <osk...@gm...> - 2010-09-18 13:55:21
|
Hi, (EDIT: I'm resending this mail without the attachment, as my previous attempt has been stuck in moderators queue for several days now. Please see issue 12339 for the illustration.) I believe that the current mantis design in many regards is experienced as cluttered and difficult to read. Therefore I've sketched a new design (for the "view bug" page only at this time). This can still probably be improved in many ways, but it's a start. I've created issue 12339 for this, but this matter should maybe be discussed on the mailing list. Quote from the issue description: Everything is in a grid layout - related gui features are not necessarily close together. E.g. in "view bug", the platform/os/osversion fields are spread out across the entire width of the screen. To many line boxes make the design appear cluttered - especially when the content of each box is missing or very small. E.g. see a bug with only a little information, the relationship/send files/watchers boxes will turn into just a bunch of lines. It should be possible to prioritise the fields better than in the current design. Some fields, like e.g. severity/status/resolution might be regarded as more important than e.g. the platform and the list of watchers (for most users most of the time). Attached is a design sketch showing some ideas for a new layout of the view bug page. (The regular mantis header still applies above it.) This layout is based on the following idea: * Not every field must necessarily be explicitly named (e.g. the platform section shows the content of platform/os/osversion as one string.) * Give more weight to the primary properties. (What is primary may be open to opinion of course.) * More secondary fields are off to the right, in a column of their own. * Putting secondary fields to the right, allows description, messages, etc. in the main column to appear higher up on the page. * Some of the action buttons that are redundant with the generic "modify bug"-button are removed. If people really want these button, it should be possible to put them back in the "Action"-section. * Color coding for e.g. status and other important values is possible, but not shown in the sketch. /Oskar |
From: Stephane R. <sro...@in...> - 2010-09-21 18:44:35
|
Oskar, I just wanted to provided a big "+1" from a user. We've been using Mantis for years and years now and have more than 7k tickets spread through our projects. The current layout of Mantis is the number one complaint I get everytime I put a new user on the system. Because they don't like the layout they immediately label Mantis as sub-par, and it's an uphill battle from then on. I have to take the time everytime to explain how "yes, Mantis does X", even if it's staring them in the face. They just draw a blank because of the initial "yuck" reaction they get. I'm used to Mantis, and I don't mind how it looks. But you have to admit it does look dated compared to what's out there, and I am getting tired of defending it within my shop. Why didn't I just "go in and friggin' fix it"? Time, skillset, etc. I haven't complained about it before, and this is not a complaint -- it's, once again, a big, big, big major +1 to your efforts. I've shown this to some of my most ... vocal ... anti-Mantis users here, and they all said "YES!" Steph On 18/09/2010 9:54 AM, Oskar Berggren wrote: > Hi, > > (EDIT: I'm resending this mail without the attachment, as my previous > attempt has been stuck in moderators queue for several days now. > Please see issue 12339 for the illustration.) > > > I believe that the current mantis design in many regards is > experienced as cluttered and difficult to read. Therefore I've > sketched a new design (for the "view bug" page only at this time). > This can still probably be improved in many ways, but it's a start. > > I've created issue 12339 for this, but this matter should maybe be > discussed on the mailing list. > > Quote from the issue description: > > Everything is in a grid layout - related gui features are not > necessarily close together. E.g. in "view bug", the > platform/os/osversion fields are spread out across the entire width of > the screen. > > To many line boxes make the design appear cluttered - especially when > the content of each box is missing or very small. E.g. see a bug with > only a little information, the relationship/send files/watchers boxes > will turn into just a bunch of lines. > > It should be possible to prioritise the fields better than in the > current design. Some fields, like e.g. severity/status/resolution > might be regarded as more important than e.g. the platform and the > list of watchers (for most users most of the time). > > > Attached is a design sketch showing some ideas for a new layout of the > view bug page. (The regular mantis header still applies above it.) > > This layout is based on the following idea: > > * Not every field must necessarily be explicitly named (e.g. the > platform section shows the content of platform/os/osversion as one > string.) > > * Give more weight to the primary properties. (What is primary may be > open to opinion of course.) > > * More secondary fields are off to the right, in a column of their own. > > * Putting secondary fields to the right, allows description, messages, > etc. in the main column to appear higher up on the page. > > * Some of the action buttons that are redundant with the generic > "modify bug"-button are removed. If people really want these button, > it should be possible to put them back in the "Action"-section. > > * Color coding for e.g. status and other important values is possible, > but not shown in the sketch. > > > /Oskar > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Michiel D. <mi...@ti...> - 2010-09-21 21:18:42
|
Ha, let's do a contest :-) We're on 23k issues, and have been using Mantis for almost 8 years. And on the whole it's a brilliant tool for what we want to achieve. I very much agree with this post. However, there are a few other things as well. Using mantis on a daily basis, you stop noticing these things, but when I talk to the occasional users, they are particularly confused by the Bug View actions. To press a button that says "Edit" they expect it to *Save* their edits, not simply take them to another page to actually perform the edits and then press some other button to actually store their edits. All they see when clicking the button is that they're taken to another page. Why isn't that a link instead? I'm not a UI expert, but I do think some people who are could have a good look at these issues. Might be a good idea to include that when taking on a UI revamp. Michiel On 21/09/10 14:18, Stephane Rouleau wrote: > Oskar, > > I just wanted to provided a big "+1" from a user. We've been using > Mantis for years and years now and have more than 7k tickets spread > through our projects. > > The current layout of Mantis is the number one complaint I get > everytime I put a new user on the system. Because they don't like the > layout they immediately label Mantis as sub-par, and it's an uphill > battle from then on. I have to take the time everytime to explain how > "yes, Mantis does X", even if it's staring them in the face. They just > draw a blank because of the initial "yuck" reaction they get. > > I'm used to Mantis, and I don't mind how it looks. But you have to > admit it does look dated compared to what's out there, and I am > getting tired of defending it within my shop. > > Why didn't I just "go in and friggin' fix it"? Time, skillset, etc. I > haven't complained about it before, and this is not a complaint -- > it's, once again, a big, big, big major +1 to your efforts. I've shown > this to some of my most ... vocal ... anti-Mantis users here, and they > all said "YES!" > > Steph > > On 18/09/2010 9:54 AM, Oskar Berggren wrote: >> Hi, >> >> (EDIT: I'm resending this mail without the attachment, as my previous >> attempt has been stuck in moderators queue for several days now. >> Please see issue 12339 for the illustration.) >> >> >> I believe that the current mantis design in many regards is >> experienced as cluttered and difficult to read. Therefore I've >> sketched a new design (for the "view bug" page only at this time). >> This can still probably be improved in many ways, but it's a start. >> >> I've created issue 12339 for this, but this matter should maybe be >> discussed on the mailing list. >> >> Quote from the issue description: >> >> Everything is in a grid layout - related gui features are not >> necessarily close together. E.g. in "view bug", the >> platform/os/osversion fields are spread out across the entire width of >> the screen. >> >> To many line boxes make the design appear cluttered - especially when >> the content of each box is missing or very small. E.g. see a bug with >> only a little information, the relationship/send files/watchers boxes >> will turn into just a bunch of lines. >> >> It should be possible to prioritise the fields better than in the >> current design. Some fields, like e.g. severity/status/resolution >> might be regarded as more important than e.g. the platform and the >> list of watchers (for most users most of the time). >> >> >> Attached is a design sketch showing some ideas for a new layout of the >> view bug page. (The regular mantis header still applies above it.) >> >> This layout is based on the following idea: >> >> * Not every field must necessarily be explicitly named (e.g. the >> platform section shows the content of platform/os/osversion as one >> string.) >> >> * Give more weight to the primary properties. (What is primary may be >> open to opinion of course.) >> >> * More secondary fields are off to the right, in a column of their own. >> >> * Putting secondary fields to the right, allows description, messages, >> etc. in the main column to appear higher up on the page. >> >> * Some of the action buttons that are redundant with the generic >> "modify bug"-button are removed. If people really want these button, >> it should be possible to put them back in the "Action"-section. >> >> * Color coding for e.g. status and other important values is possible, >> but not shown in the sketch. >> >> >> /Oskar >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > > > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Gianluca S. <gi...@gm...> - 2010-09-21 22:14:33
|
On Sat, Sep 18, 2010 at 3:54 PM, Oskar Berggren <osk...@gm...> wrote > > > I believe that the current mantis design in many regards is > experienced as cluttered and difficult to read. Therefore I've > sketched a new design (for the "view bug" page only at this time). > This can still probably be improved in many ways, but it's a start. > > I've created issue 12339 for this, but this matter should maybe be > discussed on the mailing list. > I really see your design as a huge step forward on what we have today. However, it's not the first time I've seen good alternative designs; if we have not improved as of today is probably because we have a lot of pages and no quick way to change the appearance on all of them. I think we definitely need to find someone with the right itch and skills set to see this happen. Just my 0.02 -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: Stephane R. <sro...@in...> - 2010-09-22 11:43:42
|
I went back to look at our Ticket 1, and it's dated 2003-10-03, and is still... assigned. Bad, bad developer. :) I agree with your comments regarding Save vs Edit; there are a slew of these little things that start to add up. I still stand by what I said though: the initial "omg" look at how cluttered / dated the UI looks turns off my new / casual users, and these little things are then blown out, in my opinion, completely out of proportion. I wish this would be fixed in a phased approach. Gianluca mentions this is not the first time someone has proposed a new design, and this is true. If you look through the Mantis DB, there are also numerous mentions of adding template support dating back to at least 2004. I fear that if everything is attempted to be done at the same time, we'll still be talking about it in 6 years. (Just now I'm sitting a small meeting room at a customer's site, and when I went to the Mantis BT to look at how far back the template issues went, one of the guys in the meeting, a non-Mantis user, looked at my screen and said "Nice Christmas tree" commenting on the View Issues page. He's a Fogbugz user.) Steph On 21/09/2010 4:50 PM, Michiel Dethmers wrote: > > Ha, let's do a contest :-) We're on 23k issues, and have been using > Mantis for almost 8 years. And on the whole it's a brilliant tool for > what we want to achieve. > > I very much agree with this post. However, there are a few other > things as well. Using mantis on a daily basis, you stop noticing these > things, but when I talk to the occasional users, they are particularly > confused by the Bug View actions. To press a button that says "Edit" > they expect it to *Save* their edits, not simply take them to another > page to actually perform the edits and then press some other button to > actually store their edits. All they see when clicking the button is > that they're taken to another page. Why isn't that a link instead? > > I'm not a UI expert, but I do think some people who are could have a > good look at these issues. Might be a good idea to include that when > taking on a UI revamp. > > Michiel > > On 21/09/10 14:18, Stephane Rouleau wrote: >> Oskar, >> >> I just wanted to provided a big "+1" from a user. We've been using >> Mantis for years and years now and have more than 7k tickets spread >> through our projects. >> >> The current layout of Mantis is the number one complaint I get >> everytime I put a new user on the system. Because they don't like the >> layout they immediately label Mantis as sub-par, and it's an uphill >> battle from then on. I have to take the time everytime to explain how >> "yes, Mantis does X", even if it's staring them in the face. They >> just draw a blank because of the initial "yuck" reaction they get. >> >> I'm used to Mantis, and I don't mind how it looks. But you have to >> admit it does look dated compared to what's out there, and I am >> getting tired of defending it within my shop. >> >> Why didn't I just "go in and friggin' fix it"? Time, skillset, etc. I >> haven't complained about it before, and this is not a complaint -- >> it's, once again, a big, big, big major +1 to your efforts. I've >> shown this to some of my most ... vocal ... anti-Mantis users here, >> and they all said "YES!" >> >> Steph >> >> On 18/09/2010 9:54 AM, Oskar Berggren wrote: >>> Hi, >>> >>> (EDIT: I'm resending this mail without the attachment, as my previous >>> attempt has been stuck in moderators queue for several days now. >>> Please see issue 12339 for the illustration.) >>> >>> >>> I believe that the current mantis design in many regards is >>> experienced as cluttered and difficult to read. Therefore I've >>> sketched a new design (for the "view bug" page only at this time). >>> This can still probably be improved in many ways, but it's a start. >>> >>> I've created issue 12339 for this, but this matter should maybe be >>> discussed on the mailing list. >>> >>> Quote from the issue description: >>> >>> Everything is in a grid layout - related gui features are not >>> necessarily close together. E.g. in "view bug", the >>> platform/os/osversion fields are spread out across the entire width of >>> the screen. >>> >>> To many line boxes make the design appear cluttered - especially when >>> the content of each box is missing or very small. E.g. see a bug with >>> only a little information, the relationship/send files/watchers boxes >>> will turn into just a bunch of lines. >>> >>> It should be possible to prioritise the fields better than in the >>> current design. Some fields, like e.g. severity/status/resolution >>> might be regarded as more important than e.g. the platform and the >>> list of watchers (for most users most of the time). >>> >>> >>> Attached is a design sketch showing some ideas for a new layout of the >>> view bug page. (The regular mantis header still applies above it.) >>> >>> This layout is based on the following idea: >>> >>> * Not every field must necessarily be explicitly named (e.g. the >>> platform section shows the content of platform/os/osversion as one >>> string.) >>> >>> * Give more weight to the primary properties. (What is primary may be >>> open to opinion of course.) >>> >>> * More secondary fields are off to the right, in a column of their own. >>> >>> * Putting secondary fields to the right, allows description, messages, >>> etc. in the main column to appear higher up on the page. >>> >>> * Some of the action buttons that are redundant with the generic >>> "modify bug"-button are removed. If people really want these button, >>> it should be possible to put them back in the "Action"-section. >>> >>> * Color coding for e.g. status and other important values is possible, >>> but not shown in the sketch. >>> >>> >>> /Oskar >>> >>> ------------------------------------------------------------------------------ >>> Start uncovering the many advantages of virtual appliances >>> and start using them to simplify application deployment and >>> accelerate your shift to cloud computing. >>> http://p.sf.net/sfu/novell-sfdev2dev >>> _______________________________________________ >>> mantisbt-dev mailing list >>> man...@li... >>> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >>> >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> >> >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > > > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Michelle R. <mic...@sp...> - 2010-09-23 14:24:00
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hello, everyone. <br> <br> My company having beeing use Mantis for almost 5 years and this is our main business application. I'd like to agree with you, guys. In a time of web 2.0 and Ipad/Iphone apps, Mantis needs a big improvement in its layouts. <br> <br> If some of the Mantis leaders would like to make an campaign in the community, I'll be happy to help with (limited) financial resources.<br> <div class="moz-signature"> <meta http-equiv="CONTENT-TYPE" content="text/html; "> <title></title> <meta name="GENERATOR" content="OpenOffice.org 2.4 (Linux)"> <meta name="CREATED" content="20100920;11280400"> <meta name="CHANGED" content="20100920;11303100"> <style type="text/css"> <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } P.western { so-language: pt-BR } -- </style> <p class="western" style="margin-bottom: 0.5cm;"><font face="URW Gothic L, sans-serif"><font style="font-size: 9pt;" size="2">-- <br> Atenciosamente, </font></font> </p> <p class="western"><font face="URW Gothic L, sans-serif"><font style="font-size: 9pt;" size="2">Michelle Ribeiro <br> Gerente Executiva<br> </font></font><font color="#990000"><font face="URW Gothic L, sans-serif"><font style="font-size: 9pt;" size="2">Spirit Linux </font></font></font><font face="URW Gothic L, sans-serif"><font style="font-size: 9pt;" size="2">| Linux com Profissionalismo <br> Email: <a href="mailto:mic...@sp...">mic...@sp...</a> <br> Mobile: ES (27) 8824-2641<br> Phone: ES: +55 (27) 3227-0007</font></font></p> <br> </div> <blockquote cite="mid:4C9...@in..." type="cite"> <pre wrap=""> </pre> </blockquote> </body> </html> |
From: Stephane R. <sro...@in...> - 2010-09-23 15:40:31
|
+1. I'd be willing to put money behind this. Steph On 23/09/2010 10:05 AM, Michelle Ribeiro wrote: > Hello, everyone. > > My company having beeing use Mantis for almost 5 years and this is our > main business application. I'd like to agree with you, guys. In a time > of web 2.0 and Ipad/Iphone apps, Mantis needs a big improvement in its > layouts. > > If some of the Mantis leaders would like to make an campaign in the > community, I'll be happy to help with (limited) financial resources. > > -- > Atenciosamente, > > Michelle Ribeiro > Gerente Executiva > Spirit Linux | Linux com Profissionalismo > Email: mic...@sp... <mailto:mic...@sp...> > Mobile: ES (27) 8824-2641 > Phone: ES: +55 (27) 3227-0007 > > >> > > > ------------------------------------------------------------------------------ > Nokia and AT&T present the 2010 Calling All Innovators-North America contest > Create new apps& games for the Nokia N8 for consumers in U.S. and Canada > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store > http://p.sf.net/sfu/nokia-dev2dev > > > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Gianluca S. <gi...@gm...> - 2010-09-25 21:06:45
|
On Thu, Sep 23, 2010 at 5:40 PM, Stephane Rouleau <sro...@in...> wrote: > +1. I'd be willing to put money behind this. Guys, thanks a lot for your offer. We (mantis developers) are currently evaluating how to better make use of this, and any other, direct support offers. Of course we will keep you informed about the outcome Thanks again Gianluca -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: Stephane R. <sro...@in...> - 2010-09-27 12:19:27
|
I do not have infinite funds, but there'd be costs associated for me to move away from Mantis. Moving to another free defect tracking system there'd be time costs, moving to a paid system I'd also have licensing fees. If we had just used the "Sponsor" feature, would it be any different? Thanks, and I hope this isn't causing any big internal debates. Steph On 25/09/2010 5:06 PM, Gianluca Sforna wrote: > On Thu, Sep 23, 2010 at 5:40 PM, Stephane Rouleau<sro...@in...> wrote: >> +1. I'd be willing to put money behind this. > Guys, thanks a lot for your offer. > > We (mantis developers) are currently evaluating how to better make use > of this, and any other, direct support offers. > > Of course we will keep you informed about the outcome > > Thanks again > > Gianluca > > > |
From: David H. <hic...@op...> - 2010-09-27 13:28:52
|
On Mon, 2010-09-27 at 08:19 -0400, Stephane Rouleau wrote: > If we had just used the "Sponsor" feature, would it be any different? The problem is more one of how an open source project receives donations and forwards those donations to developers. I imagine you'd have to set up a non-for-profit organisation in each country receiving and forwarding donations - if that is even possible for open source software development projects. This would be required for taxation purposes and would also encourage donations from businesses that would want to make the most of the tax benefits of donating. For instance, the Mediawiki project has been assisted by development funded by the Wikimedia Foundation[1]. Administration issues aside, there is also the issue of who would be selected to receive donations and carry out the work. Current full time developers are going to be limited in their ability to contribute because they're already working a full time job and probably don't want to work 70 hours a week. I don't see this project being large enough to provide income stability for a developer to work full time on the project. You'd most likely be looking for self employed developers who can assign X amount of time out of their schedule to do some work on MantisBT. They should be expecting "market rates" for their work done towards MantisBT. The scale of work required for UI upgrades is quite large, so I'm guessing at USD$50k+? It's not just the UI that needs updating (HTML/CSS) - it's a case of refactoring every single .php file, removing and replacing large chunks of API (print_api, html_api, etc) and performing testing and bug fixing. I would have thought users (businesses or individuals) interested in helping improve MantisBT could do so via: * Encouraging other people to use MantisBT. * Allocating time for employees to improve MantisBT and send those improvements upstream so we can commit it to the main repository. * Testing MantisBT features and creating detailed bug reports. * Hiring students (or contractors) to work on MantisBT features your business/project is interested in, then following through and ensuring those changes are merged upstream. Many MantisBT users have already customised their bug trackers and developed new features/code. The problem is that much of this code is ugly hacky stuff that is designed to work for one user under special circumstances rather than 1000's of other MantisBT users. We frequently receive "patches" on the bug tracker which are just heavily hacked up PHP files from 3 year old copies of MantisBT. No file diffs (certainly not Git formatted patch sets!). This is of limited use to the project. What is needed is a thorough effort to meet the "coding standards" of the project, make use of Git for development work, communicate ideas with other developers (and users), test changes and support those changes. Otherwise code simply won't get merged. >From the list of contribution methods I listed above, I'd probably have to say that employee contributions are the most valuable. One only has to look to the Linux Kernel project for reasons why. > Thanks, and I hope this isn't causing any big internal debates. Not at all. I'd be really interested in hearing from mantisbt-dev readers who have more experience with open source business models. Regards, David [1] http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_user-friendly_for_new_volunteer_writers |
From: Stephane R. <sro...@in...> - 2010-09-27 17:01:13
|
Thanks David, money always complicates things I know. Let's just assume that we're looking at something in the 50k USD ballpark, that's several orders of magnitude what I've seen used in the Sponsor field so far. So basically what you're saying is that the "Sponsor" feature currently in place on the Mantis BT would not work at all in this case. I don't know what a full-time PHP coder makes in the US, I'm not in that field of work unfortunately otherwise I could have perhaps done some of the work myself (with the 1/2 hour of free time I get a week). Let's just work with effort instead; the estimate for this is what, 4 months? 6 months? I'm actually an employer. I don't currently have PHP coders on staff, but we're looking at extending our service offering by touching server-side web development (PHP, Ruby, etc), and knowing that I could contribude this way by donating some of their time may be interesting ... once I have them actually on my staff. (But then money rears its ugly head: if I donate this time, why would others get paid?) I realize it's a lot of work, but I feel we're at a crossroad here, at least as far as I'm concerned. Mantis is fine for what it is, but as I said in my original reply to Oskar, I'm getting weary of having to defend the tool, both internally with my own coders, and externally with business partners. Steph On 27/09/2010 9:26 AM, David Hicks wrote: > On Mon, 2010-09-27 at 08:19 -0400, Stephane Rouleau wrote: >> If we had just used the "Sponsor" feature, would it be any different? > The problem is more one of how an open source project receives donations > and forwards those donations to developers. I imagine you'd have to set > up a non-for-profit organisation in each country receiving and > forwarding donations - if that is even possible for open source software > development projects. This would be required for taxation purposes and > would also encourage donations from businesses that would want to make > the most of the tax benefits of donating. For instance, the Mediawiki > project has been assisted by development funded by the Wikimedia > Foundation[1]. > > Administration issues aside, there is also the issue of who would be > selected to receive donations and carry out the work. Current full time > developers are going to be limited in their ability to contribute > because they're already working a full time job and probably don't want > to work 70 hours a week. I don't see this project being large enough to > provide income stability for a developer to work full time on the > project. > > You'd most likely be looking for self employed developers who can assign > X amount of time out of their schedule to do some work on MantisBT. They > should be expecting "market rates" for their work done towards MantisBT. > The scale of work required for UI upgrades is quite large, so I'm > guessing at USD$50k+? It's not just the UI that needs updating > (HTML/CSS) - it's a case of refactoring every single .php file, removing > and replacing large chunks of API (print_api, html_api, etc) and > performing testing and bug fixing. > > I would have thought users (businesses or individuals) interested in > helping improve MantisBT could do so via: > * Encouraging other people to use MantisBT. > * Allocating time for employees to improve MantisBT and send those > improvements upstream so we can commit it to the main repository. > * Testing MantisBT features and creating detailed bug reports. > * Hiring students (or contractors) to work on MantisBT features your > business/project is interested in, then following through and ensuring > those changes are merged upstream. > > Many MantisBT users have already customised their bug trackers and > developed new features/code. The problem is that much of this code is > ugly hacky stuff that is designed to work for one user under special > circumstances rather than 1000's of other MantisBT users. We frequently > receive "patches" on the bug tracker which are just heavily hacked up > PHP files from 3 year old copies of MantisBT. No file diffs (certainly > not Git formatted patch sets!). This is of limited use to the project. > What is needed is a thorough effort to meet the "coding standards" of > the project, make use of Git for development work, communicate ideas > with other developers (and users), test changes and support those > changes. Otherwise code simply won't get merged. > > > From the list of contribution methods I listed above, I'd probably have > to say that employee contributions are the most valuable. One only has > to look to the Linux Kernel project for reasons why. > >> Thanks, and I hope this isn't causing any big internal debates. > Not at all. > > I'd be really interested in hearing from mantisbt-dev readers who have > more experience with open source business models. > > Regards, > > David > > > [1] > http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_user-friendly_for_new_volunteer_writers > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: John R. <jr...@le...> - 2010-09-27 17:54:39
|
On 09/27/2010 01:01 PM, Stephane Rouleau wrote: > Thanks David, money always complicates things I know. I can't stress this point enough. > Let's just assume that we're looking at something in the 50k USD > ballpark, that's several orders of magnitude what I've seen used in the > Sponsor field so far. So basically what you're saying is that the > "Sponsor" feature currently in place on the Mantis BT would not work at > all in this case. The biggest problem with the "sponsoring" feature of Mantis is just that it includes zero support for actually managing the money transactions, and especially for guaranteeing that the money will actually be there for when the issue is completed, eg. escrow. There have been plenty of "sponsored" issues closed on our tracker where the money has never changed hands. > I don't know what a full-time PHP coder makes in the US, As a point of reference, my current position unrelated to Mantis is on the order of 75k/year, for a rather generic PHP development position. > I'm actually an employer. I don't currently have PHP coders on staff, > but we're looking at extending our service offering by touching > server-side web development (PHP, Ruby, etc), and knowing that I could > contribude this way by donating some of their time may be interesting > ... once I have them actually on my staff. (But then money rears its > ugly head: if I donate this time, why would others get paid?) Paying MantisBT developers for their work is just messy IMO, esp with international regulations and taxes involved, and only serves to complicate the situation. I would actually greatly prefer that you contribute your employee's time to learning the MantisBT codebase, joining us in discussion of the features, and then developing the features in the open and working towards getting them accepted into our repository. Time is always the biggest constraint on our existing development efforts, and contributing developer time and effort is IMO the best way to get things done. For an example, when my previous employer wanted to make improvements to MantisBT, I was tasked with working with the upstream project to implement and contribute features and bugfixes to the project as part of my 9-5 responsibilities. The end result is that I was given commit access to the main repository, and eventually worked to create the plugin system. > I realize it's a lot of work, but I feel we're at a crossroad here, at > least as far as I'm concerned. Mantis is fine for what it is, but as I > said in my original reply to Oskar, I'm getting weary of having to > defend the tool, both internally with my own coders, and externally with > business partners. I know that for the few years I've been around, the look and feel of Mantis has always been the biggest complaint, and has come up many times from the community as something to change, but without developers with enough time dedicated to that one task, it's too big of a change to otherwise get implemented on spare time alone. Cheers -- John Reese LeetCode.net |
From: Robert M. <rob...@gm...> - 2010-09-27 19:23:07
|
On Mon, Sep 27, 2010 at 8:55 PM, John Reese <jr...@le...> wrote: > > Paying MantisBT developers for their work is just messy IMO, esp with > international regulations and taxes involved, and only serves to > complicate the situation. I would actually greatly prefer that you > contribute your employee's time to learning the MantisBT codebase, > joining us in discussion of the features, and then developing the > features in the open and working towards getting them accepted into our > repository. Time is always the biggest constraint on our existing > development efforts, and contributing developer time and effort is IMO > the best way to get things done. A huge +1 on that. One or more developers willing to work together with us to refresh MantisBT's look is the best we can hope for. -- Sent from my (old) computer |
From: Robert M. <rob...@gm...> - 2010-09-28 06:58:28
|
To follow up on my comments, I think that we - as a development team - should come up with a clear roadmap related to the redesign of MantisBT. While stating that it will be difficult to achieve is nothing but correct, it's not bringing us closer to a resolution of what I perceive to be the greatest weakness that we have. I must admit that I have not worked with the rendering APIs at all, but I think that such a task would at least involve: 1. Redesign of the view issue page ( kudos to Oskar for picking up this one ). 2. Redesign of the view issues page 3. Redesign of the report issue page 4. Decision on how to implement changes . Should we refactor the core APIs to support templating for these changes? Yes, it makes sense, but on the other hand it might not be required. A template promotes good coding practices, but we should weigh the benefits of making this change and then implementing the design as opposed to the disadvantages of yet again postponing a much-deserved redesign. 5. Implement changes in the core APIs, if needed. 6. Implement changes on the view issue page. 7. Community feedback 8. Fix, and finish implementation. All that we - again , as a development team - must do is 4 - decision on how to implement the changes , and perhaps assist in 5 - implement changes in the core APIs. So my suggestion is 1. Evaluate what the best way of implementing these changes is. 2. Create any needed support in the core APIs . 3. Steadily apply changes to the design, as it unfolds. I don't necessarily see adopting a templating engine as a prerequisite, simply because it seems a huge task in itself. Thoughts? Robert On Mon, Sep 27, 2010 at 10:23 PM, Robert Munteanu <rob...@gm...> wrote: > On Mon, Sep 27, 2010 at 8:55 PM, John Reese <jr...@le...> wrote: >> >> Paying MantisBT developers for their work is just messy IMO, esp with >> international regulations and taxes involved, and only serves to >> complicate the situation. I would actually greatly prefer that you >> contribute your employee's time to learning the MantisBT codebase, >> joining us in discussion of the features, and then developing the >> features in the open and working towards getting them accepted into our >> repository. Time is always the biggest constraint on our existing >> development efforts, and contributing developer time and effort is IMO >> the best way to get things done. > > A huge +1 on that. One or more developers willing to work together > with us to refresh MantisBT's look is the best we can hope for. > > > -- > Sent from my (old) computer > -- Sent from my (old) computer |
From: Michiel D. <mi...@ti...> - 2010-09-28 09:54:10
|
With my own OS project, phpList, I've just spend easily a few months with a coder and a CSS-er to revamp the dramatically outdated interface. I can tell you, it's not for the faint hearted, but once you get the basics down, it's really worth it. phpList has about the same age as mantis. I have no in-depth understanding of the mantis code and how it separates the business layer from the display layer, so maybe many of these things are already in place, but I would advice to approach it using widgets. Do not go through designs page by page. Instead you build a library of interface elements that each work out their own way to display things. Then in the page code, you instantiate a widget and add content to it and call a final method to display it's output. Also, with current web technology, tables are out. Everything sits in a div or span with a class. Name the classes by "function" and not by display aspects, eg class="action" and not class="leftmenu" (who knows, the menu might go to the right) Also, stylers love "UL"s for listings. Basically, the coder determines the elements that go in a page and the styler determines how they look and where they should go. I have for example a "listingObject" that in the code I add elements to with columns. At the end, I say "give me your output". It used to output the entire listing in a table, and now it simply returns divs with classes so that the styler can get his hands on it. Michiel On 28/09/10 07:58, Robert Munteanu wrote: > To follow up on my comments, I think that we - as a development team - > should come up with a clear roadmap related to the redesign of > MantisBT. > > While stating that it will be difficult to achieve is nothing but > correct, it's not bringing us closer to a resolution of what I > perceive to be the greatest weakness that we have. > > I must admit that I have not worked with the rendering APIs at all, > but I think that such a task would at least involve: > > 1. Redesign of the view issue page ( kudos to Oskar for picking up this one ). > 2. Redesign of the view issues page > 3. Redesign of the report issue page > > 4. Decision on how to implement changes . Should we refactor the core > APIs to support templating for these changes? Yes, it makes sense, but > on the other hand it might not be required. A template promotes good > coding practices, but we should weigh the benefits of making this > change and then implementing the design as opposed to the > disadvantages of yet again postponing a much-deserved redesign. > 5. Implement changes in the core APIs, if needed. > > 6. Implement changes on the view issue page. > 7. Community feedback > 8. Fix, and finish implementation. > > All that we - again , as a development team - must do is 4 - decision > on how to implement the changes , and perhaps assist in 5 - implement > changes in the core APIs. > > So my suggestion is > > 1. Evaluate what the best way of implementing these changes is. > 2. Create any needed support in the core APIs . > 3. Steadily apply changes to the design, as it unfolds. > > I don't necessarily see adopting a templating engine as a > prerequisite, simply because it seems a huge task in itself. > > Thoughts? > > Robert > > On Mon, Sep 27, 2010 at 10:23 PM, Robert Munteanu > <rob...@gm...> wrote: > >> On Mon, Sep 27, 2010 at 8:55 PM, John Reese <jr...@le...> wrote: >> >>> Paying MantisBT developers for their work is just messy IMO, esp with >>> international regulations and taxes involved, and only serves to >>> complicate the situation. I would actually greatly prefer that you >>> contribute your employee's time to learning the MantisBT codebase, >>> joining us in discussion of the features, and then developing the >>> features in the open and working towards getting them accepted into our >>> repository. Time is always the biggest constraint on our existing >>> development efforts, and contributing developer time and effort is IMO >>> the best way to get things done. >>> >> A huge +1 on that. One or more developers willing to work together >> with us to refresh MantisBT's look is the best we can hope for. >> >> >> -- >> Sent from my (old) computer >> >> > > > |
From: Daryn W. <da...@ii...> - 2010-09-28 15:13:30
|
The roadmap is basically in place it just isn't documented well. I and several others are already working towards making a redesign possible. We are adding classes and ids as well as removing layout tables where possible. For instance, the menus are now in ul lists with css attributes. Probably the biggest task is separating the business logic from the display logic in the individual pages. Once this is completed it will be much easier to move to a template system. I have personally used phptal, smarty, and plain php and by far my favorite is phptal. We've had discussions Ad nauseam on this list regarding template systems and I don't care to start a war again. However, not knowing does affect my willingness to commit time and energy to move this cause forward. So, IMHO this is the roadmap in two parts: 1. Enlist a designer, preferably a ui expert to draw up some page designs for us. There appears to be at least some available skill in the community as people have posted designs in the tracker as well as previous postings on this list. That should be a good starting point. 2. _Get agreement _in the community or at least the core devs on a final design. Meanwhile: 1. _Get agreement _among core devs on whether or not to use a template system and _pick one_. (PHPTal ftw) 2. Complete separation of business and display logic in individual pages ( In progress ) 3. Create a class for handling global template variables to replace the html_api functions. I have created a MantisTemplate plugin that is engine agnostic for internal use. I believe this could be a good foundation to start with but it needs a quite bit of work and should be reviewed by some other core devs to be sure the design makes sense. 4. Create layouts using the template system or plain php. ( Need the design ) 5. Determine how to replace print_api functions using the new system and implement changes. 6. Convert individual pages While a template system is certainly not required to do a redesign in my opinion it makes sense to do it now. I don't believe that using a template system will create much of a delay in completing a redesign if we have a clear path forward and people interested in making it happen. I for one am interested in making this happen. Unless another core dev has a burning desire to manage this process I would be willing to do so. Regards, Daryn Warriner On 09/28/2010 01:58 AM, Robert Munteanu wrote: > To follow up on my comments, I think that we - as a development team - > should come up with a clear roadmap related to the redesign of > MantisBT. > > While stating that it will be difficult to achieve is nothing but > correct, it's not bringing us closer to a resolution of what I > perceive to be the greatest weakness that we have. > > I must admit that I have not worked with the rendering APIs at all, > but I think that such a task would at least involve: > > 1. Redesign of the view issue page ( kudos to Oskar for picking up this one ). > 2. Redesign of the view issues page > 3. Redesign of the report issue page > > 4. Decision on how to implement changes . Should we refactor the core > APIs to support templating for these changes? Yes, it makes sense, but > on the other hand it might not be required. A template promotes good > coding practices, but we should weigh the benefits of making this > change and then implementing the design as opposed to the > disadvantages of yet again postponing a much-deserved redesign. > 5. Implement changes in the core APIs, if needed. > > 6. Implement changes on the view issue page. > 7. Community feedback > 8. Fix, and finish implementation. > > All that we - again , as a development team - must do is 4 - decision > on how to implement the changes , and perhaps assist in 5 - implement > changes in the core APIs. > > So my suggestion is > > 1. Evaluate what the best way of implementing these changes is. > 2. Create any needed support in the core APIs . > 3. Steadily apply changes to the design, as it unfolds. > > I don't necessarily see adopting a templating engine as a > prerequisite, simply because it seems a huge task in itself. > > Thoughts? > > Robert > |
From: Robert M. <rob...@gm...> - 2010-09-28 20:05:39
|
On Tue, Sep 28, 2010 at 6:13 PM, Daryn Warriner <da...@ii...> wrote: > The roadmap is basically in place it just isn't documented well. I and > several others are already working towards making a redesign possible. We > are adding classes and ids as well as removing layout tables where > possible. For instance, the menus are now in ul lists with css > attributes. Probably the biggest task is separating the business logic > from the display logic in the individual pages. Once this is completed it > will be much easier to move to a template system. > > I have personally used phptal, smarty, and plain php and by far my favorite > is phptal. We've had discussions Ad nauseam on this list regarding template > systems and I don't care to start a war again. However, not knowing does > affect my willingness to commit time and energy to move this cause forward. IMO , the one(s) making the choice should be the one(s) working on it. I will kindly keep my mouth shut about which template engine to choose, as long as we pick one. It's going to be vastly superior to _no_ templating system. > > So, IMHO this is the roadmap in two parts: > > 1. Enlist a designer, preferably a ui expert to draw up some page > designs for us. There appears to be at least some available skill in the > community as people have posted designs in the tracker as well as previous > postings on this list. That should be a good starting point. > 2. Get agreement in the community or at least the core devs on a final > design. Oskar did a great start IMO. Why not spread the word about a design competition for MantisBT ? I suspect we do have a number of blog readers / twitter follower / mailing list participants. And many more people who would like to see MantisBT getting a facelift. I could also inform my 32 twitter followers about it :-) > > Meanwhile: > > 1. Get agreement among core devs on whether or not to use a template > system and pick one. (PHPTal ftw) As I said above. Whatever ftw :-) If PHPTal is what you feel would fit in best, let's do just that. > 2. Complete separation of business and display logic in individual pages > ( In progress ) > 3. Create a class for handling global template variables to replace the > html_api functions. > > I have created a MantisTemplate plugin that is engine agnostic for internal > use. I believe this could be a good foundation to start with but it needs a > quite bit of work and should be reviewed by some other core devs to be sure > the design makes sense. > > 4. Create layouts using the template system or plain php. ( Need the > design ) > 5. Determine how to replace print_api functions using the new system and > implement changes. > 6. Convert individual pages > > While a template system is certainly not required to do a redesign in my > opinion it makes sense to do it now. I don't believe that using a template > system will create much of a delay in completing a redesign if we have a > clear path forward and people interested in making it happen. I for one am > interested in making this happen. +1 from me. I can assist with testing and perhaps HTML/CSS/JS issues as well. > > Unless another core dev has a burning desire to manage this process I would > be willing to do so. +1 here as well. Robert > > Regards, > > Daryn Warriner > > > On 09/28/2010 01:58 AM, Robert Munteanu wrote: > > To follow up on my comments, I think that we - as a development team - > should come up with a clear roadmap related to the redesign of > MantisBT. > > While stating that it will be difficult to achieve is nothing but > correct, it's not bringing us closer to a resolution of what I > perceive to be the greatest weakness that we have. > > I must admit that I have not worked with the rendering APIs at all, > but I think that such a task would at least involve: > > 1. Redesign of the view issue page ( kudos to Oskar for picking up this one > ). > 2. Redesign of the view issues page > 3. Redesign of the report issue page > > 4. Decision on how to implement changes . Should we refactor the core > APIs to support templating for these changes? Yes, it makes sense, but > on the other hand it might not be required. A template promotes good > coding practices, but we should weigh the benefits of making this > change and then implementing the design as opposed to the > disadvantages of yet again postponing a much-deserved redesign. > 5. Implement changes in the core APIs, if needed. > > 6. Implement changes on the view issue page. > 7. Community feedback > 8. Fix, and finish implementation. > > All that we - again , as a development team - must do is 4 - decision > on how to implement the changes , and perhaps assist in 5 - implement > changes in the core APIs. > > So my suggestion is > > 1. Evaluate what the best way of implementing these changes is. > 2. Create any needed support in the core APIs . > 3. Steadily apply changes to the design, as it unfolds. > > I don't necessarily see adopting a templating engine as a > prerequisite, simply because it seems a huge task in itself. > > Thoughts? > > Robert > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > -- Sent from my (old) computer |
From: Gianluca S. <gi...@gm...> - 2010-09-28 21:13:44
|
On Tue, Sep 28, 2010 at 5:13 PM, Daryn Warriner <da...@ii...> wrote: > While a template system is certainly not required to do a redesign in my > opinion it makes sense to do it now. I don't believe that using a template > system will create much of a delay in completing a redesign if we have a > clear path forward and people interested in making it happen. I for one am > interested in making this happen. > > Unless another core dev has a burning desire to manage this process I would > be willing to do so. As Robert said in another reply, the one actually doing stuff can choose tools ;) However, I'll restate my opinion here, just for completeness. I think the most important thing here is to rework how we output HTML so that it's more easily style-able; to this end, I think Michiel's advices are really important to take into account. Once we have a new HTML structure, friendlier to CSS savvy people, I think we will see more different styles that we can handle (think wordpress...) Then, some results are probably not going to be achieved just by CSS tricks, so it will be necessary to have a mean to also edit the resulting HTML. If you think changing phptal template files is good for this purpose, then definitely go for it. I think I'd just be content with simpler Zend view scripts, http://framework.zend.com/manual/en/zend.view.scripts.html but I see ZF is good enough we don't need to choose either that _or_ phptal: http://www.google.com/search?q=zend+phptal So the actual templating engine we decide to use is probably not really important. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: Stephane R. <sro...@in...> - 2010-09-28 21:51:16
|
I know it's sexy, I know it's fun, I know templates are cool, I know refactoring needs to be done because the code base is old, business logic is mixed with the output, etc. However, as I said before, there were talks of using template systems back in 2004. I doubt the developers have more time now than they did then. Couldn't a phased approach be used? Couldn't /just/ the output be changed, keeping the business logic where it is now, and once the fresh coat of paint is done get the template done within the next 6 years? Perhaps it's completely impossible with the current code base, I don't know -- I'm just (mainly) a C++ programmer, but I've seen my share of impossible-to-change code. I agree 100% with Robert's way of going at it, where templating is not the actual goal, just a tool that may or may not help. In fact, reading this thread, I'm even tempted to pick up PHP. I've done some muddling around with it in the past, enough to be dangerous. :) Steph On 28/09/2010 5:13 PM, Gianluca Sforna wrote: > On Tue, Sep 28, 2010 at 5:13 PM, Daryn Warriner<da...@ii...> wrote: >> While a template system is certainly not required to do a redesign in my >> opinion it makes sense to do it now. I don't believe that using a template >> system will create much of a delay in completing a redesign if we have a >> clear path forward and people interested in making it happen. I for one am >> interested in making this happen. >> >> Unless another core dev has a burning desire to manage this process I would >> be willing to do so. > As Robert said in another reply, the one actually doing stuff can > choose tools ;) > > However, I'll restate my opinion here, just for completeness. > I think the most important thing here is to rework how we output HTML > so that it's more easily style-able; to this end, I think Michiel's > advices are really important to take into account. > Once we have a new HTML structure, friendlier to CSS savvy people, I > think we will see more different styles that we can handle (think > wordpress...) > > Then, some results are probably not going to be achieved just by CSS > tricks, so it will be necessary to have a mean to also edit the > resulting HTML. > > If you think changing phptal template files is good for this purpose, > then definitely go for it. > > I think I'd just be content with simpler Zend view scripts, > http://framework.zend.com/manual/en/zend.view.scripts.html > > but I see ZF is good enough we don't need to choose either that _or_ phptal: > http://www.google.com/search?q=zend+phptal > > So the actual templating engine we decide to use is probably not > really important. > |
From: Enisséo <en...@gm...> - 2010-09-28 23:43:19
|
Hi all! I did not follow all the talk about themes and templates but on this subject I generally prefer not using a template engine: I find that using another level of abstraction (templating language, like Smarty) is often useless and too constraining (special loops/variables...). In addition, a template language as a true interest only if the templates are only made by persons not knowing PHP (and not willing to or able to) or in the case of a common template language between platforms/technologies (Ajax&PHP generated, for example). A good, simple and sufficient template engine: phpti.com or similar. Enisseo |
From: Gianluca S. <gi...@gm...> - 2010-09-29 06:59:46
|
On Wed, Sep 29, 2010 at 1:43 AM, Enisséo <en...@gm...> wrote: > In addition, a template language as a true interest only if the templates > are only made by persons not knowing PHP (and not willing to or able to) or > in the case of a common template language between platforms/technologies > (Ajax&PHP generated, for example). In general terms that's correct. However, it all boils down to how much PHP you need to know to do something useful. Wordpress themes are PHP scripts, but that was hardly a roadblock for building a huge ecosystem of free and pay-for-use themes. > A good, simple and sufficient template engine: phpti.com or similar. At first glance, I'd agree that's non-obstrusive enough for a causal theme designer wannabe. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: John R. <jr...@le...> - 2010-09-29 16:32:16
|
On 09/28/2010 07:43 PM, Enisséo wrote: > I did not follow all the talk about themes and templates but on this > subject I generally prefer not using a template engine: I find that > using another level of abstraction (templating language, like Smarty) is > often useless and too constraining (special loops/variables...). In general, I would agree with you, but in the case of web apps like MantisBT, the use of a template engine does make sense. With a proper template engine, you get a certain amount of functionality "for free" when you write the template, that you would normally have to keep track of and make sure you're not forgetting by writing the pure PHP. For instance, sanitizing of output is something that can be automated by the template system, rather than needing to call string_display*() as we do now; localized strings is another bonus. Granted, there are a few cases where each of those don't make 100% sense, and so it's best to try and cover the exceptional needs before making a final decision for a templating engine, but I still feel it would be better to automate those needs as part of the template than introducing a lot of XSS bugs (like what we have fixed recently) by forgetting to clean everything on its way to the client. -- John Reese LeetCode.net |
From: Udo S. <u.s...@gm...> - 2010-09-29 17:19:18
|
Apologies for entering into this discussion. I subscribed 2-3 days ago, so I'm missing a lot of the discussion. I noticed that there is a lot of discussion of whether or not to use a templating engine. From the last e-mail (John Reese) I interpret that it is based on verifying and sanitizing content and probably most important, to be able to implement this in a fast & secure way. Btw, I had an issue regarding this (yesterday). I used the hash "#" in a custom field name, so the sorting of that column broke... In my opinion (and I assume in yours too) the user should never be allowed to enter a string which contains characters that break a certain functionality. Correct? To implement such a functianlity you don't need a templating engine... Use a good PHP Framework instead. E.g. Zend Framework Take a look how this is tackled with the Zend_Validator component: - e-mail address validation: http://framework.zend.com/manual/en/zend.validate.set.html#EmailAddress - Regex validation (the most versatile): http://framework.zend.com/manual/en/zend.validate.set.html#Regex - String length: http://framework.zend.com/manual/en/zend.validate.set.html#StringLength Also check out Zend_Filter: http://framework.zend.com/manual/1.10/en/zend.filter.set.html - E.g.: Strip all HTML & PHP tags from being considered (XSS, etc.): http://framework.zend.com/manual/1.10/en/zend.filter.set.html#StripTags Just some input from my side... Best, Udo |
From: Stephane R. <sro...@in...> - 2010-09-29 17:29:10
|
Welcome to the list, Udo! The list archives can be found online, but as far as this particular thread is concerned, we're mainly discussing the Mantis "look." Oskar posted a new look on Sept 18th, and since then there's been all sorts of discussions around this, templates being one way to reach this ultimate goal. While there's some disagreement on how to reach nirvana, I have yet to see one person claim that the current look is fine the way it is. Steph On 29/09/2010 1:19 PM, Udo Schochtert wrote: > Apologies for entering into this discussion. I subscribed 2-3 days > ago, so I'm missing a lot of the discussion. > > I noticed that there is a lot of discussion of whether or not to use a > templating engine. From the last e-mail (John Reese) I interpret that > it is based on verifying and sanitizing content and probably most > important, to be able to implement this in a fast & secure way. > > Btw, I had an issue regarding this (yesterday). I used the hash "#" in > a custom field name, so the sorting of that column broke... In my > opinion (and I assume in yours too) the user should never be allowed > to enter a string which contains characters that break a certain > functionality. Correct? > > To implement such a functianlity you don't need a templating engine... > Use a good PHP Framework instead. E.g. Zend Framework > Take a look how this is tackled with the Zend_Validator component: > > * e-mail address validation: > http://framework.zend.com/manual/en/zend.validate.set.html#EmailAddress > * Regex validation (the most versatile): > http://framework.zend.com/manual/en/zend.validate.set.html#Regex > * String length: > http://framework.zend.com/manual/en/zend.validate.set.html#StringLength > > Also check out Zend_Filter: > http://framework.zend.com/manual/1.10/en/zend.filter.set.html > > * E.g.: Strip all HTML & PHP tags from being considered (XSS, > etc.): > http://framework.zend.com/manual/1.10/en/zend.filter.set.html#StripTags > > Just some input from my side... > > Best, Udo > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > > > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Udo S. <u.s...@gm...> - 2010-09-29 19:48:06
|
Thanks for pointing this out Steph. I took a look at http://www.mantisbt.org/bugs/view.php?id=12339 and I like it. A very good basis. There is some information missing, but can be included. I bet Oskar knows this but wanted to keep complexity low. Always a good point. Using a MVC architecture it should not be too hard to implement and adapt on the go. The proposed design has my vote ;) simplicity rules! Udo On Wed, Sep 29, 2010 at 7:29 PM, Stephane Rouleau <sro...@in...>wrote: > Welcome to the list, Udo! The list archives can be found online, but > as far as this particular thread is concerned, we're mainly discussing > the Mantis "look." Oskar posted a new look on Sept 18th, and since then > there's been all sorts of discussions around this, templates being one > way to reach this ultimate goal. > > While there's some disagreement on how to reach nirvana, I have yet to > see one person claim that the current look is fine the way it is. > > Steph |