Robert Munteanu
2014-08-19 12:38:46 UTC
Hi,
I'd like to split the discussion into its own separate thread, both
for keeping the discussion on the new theme separate and for having a
clear link to point to the results of the discussion on including
Boostrap.
Here's the 'checklist' that I proposed when reviewing external libraries [1]
- Technical fit
I believe boostrap is one of the most used and productive frontend
frameworks. As such, it is a good technical fit for MantisBT.
- License compatibility
License is MIT [2], I see no conflicts here.
- Recent development activity
9k+ commits, 500+ contributors according to [3]
- Community size/support
Community support via irc and stackoverflow, accoring to [4] .
I think all four criteria are met, and boostrap can be included in
MantisBT, so here's my '+1'.
On a side note, I think that if Rafik is more familiar and confident
using bootstrap, we should follow his approach. I don't see any value
in debating alternative frontend frameworks ; we don't have a terribly
complex use case, and any of them would do frankly. If Rafik chose
bootstrap, so be it.
Robert
[1]: https://www.mantisbt.org/wiki/doku.php/mantisbt:development_process#changing_external_libraries
[2]: https://github.com/twbs/bootstrap/blob/master/LICENSE
[3]: https://github.com/twbs/bootstrap
[4]: https://github.com/twbs/bootstrap#community
I'd like to split the discussion into its own separate thread, both
for keeping the discussion on the new theme separate and for having a
clear link to point to the results of the discussion on including
Boostrap.
Here's the 'checklist' that I proposed when reviewing external libraries [1]
- Technical fit
I believe boostrap is one of the most used and productive frontend
frameworks. As such, it is a good technical fit for MantisBT.
- License compatibility
License is MIT [2], I see no conflicts here.
- Recent development activity
9k+ commits, 500+ contributors according to [3]
- Community size/support
Community support via irc and stackoverflow, accoring to [4] .
I think all four criteria are met, and boostrap can be included in
MantisBT, so here's my '+1'.
On a side note, I think that if Rafik is more familiar and confident
using bootstrap, we should follow his approach. I don't see any value
in debating alternative frontend frameworks ; we don't have a terribly
complex use case, and any of them would do frankly. If Rafik chose
bootstrap, so be it.
Robert
[1]: https://www.mantisbt.org/wiki/doku.php/mantisbt:development_process#changing_external_libraries
[2]: https://github.com/twbs/bootstrap/blob/master/LICENSE
[3]: https://github.com/twbs/bootstrap
[4]: https://github.com/twbs/bootstrap#community
There are a couple of popular web frameworks: Bootstrap & Foundation
+ If you scan both bootstrap & foundation docs, you will see the same
features, similar markup and same web components.
+ Bootstrap has a much bigger ecosystem. It came first and was backed by
twitter. It captured developers mindshare early on and became the de-facto
http://techcrunch.com/2013/07/28/bootstrap-3-goes-mobile-first-now-reportedly-powers-1-of-the-web/
http://blog.meanpath.com/4-7m-sites-using-bootstrap-vs-334k-on-foundation/
As such, bootstrap has the lion share of docs, plugins, free and commercial
themes (like the one used with Mantis) … etc
+ Other than that, it is hard to differentiate between both frameworks. Here
http://blog.teamtreehouse.com/use-bootstrap-or-foundation
What about JQuery Mobile?
It is a great framework for building mobile user interfaces. I started using
it when it was in early alpha and was a big fan. That’s until Bootstrap v3.0
came along. Bootstrap v3 is far superior framework for building responsive
interfaces that works on desktop, tablet and mobile.
What about Theme Roller?
That’s not a framework. It is a feature available in jqueryui.com to allow
users to customize the look and feel of jqueryui components. The output of
the theme roller is a custom css file to apply alongside the core jqueryui
library. If you want the same for mantis, you need to build it. It won’t
matter if the underlying framework is Bootstrap or Foundation.
So far, the works been done by someone that has never done a commit to
mantis before
There is always a first time
The new layout would look great for a service (like mantis hub),
Nothing in this work was customized for MantisHub.
The sidebar design is increasingly popular choice (Github, Jira, BitBucket)
because of the popularity of widescreen monitors. With widescreen, you have
more horizontal space to work with and less vertical space. Using vertical
space to show a navigation menu with 5 links is just a waste of precious
user work area.
-Rafik
My main concern is that we evaluate options properly - any decision we take
now is something that the whole dev-team and any plugin author will be
using.
So far, the works been done by someone that has never done a commit to
mantis before - whilst it's fairly clear that they are not stupid, at the
same time, there's historical decisions and historical roadmap items and
plans etc that may not have been considered. It may be that after this work,
we never see the author again. Our published contribution guidelines state
to talk to the dev list first etc etc etc.
Hopefully Rafik will submit a PR with whitespace tidied up and splitting out
some of the non-design changes (i.e. jquery) so we can actually have a
proper look at the work, but there's decisions in that PR that we've already
discussed and decided on a path 'for now'.
For example,
In october 2013 Victor send a mail about upgrading JQuery from 1.7.2 to 1.9
or 2.0
Robert replied stating that moving to 2.0 would rule out IE8
Etc
I replied with what I deemed a favourite question: "what browsers do *we
support*? :)"
A Mantis user replied to the converstation stating about being careful about
browser support as they only have IE8
Robert replied stating IE8 is here to stay.
I might have got the order slightly wrong in the above, but the end outcome
I believe was we updated master from jquery 1.7.2 to 1.9.1
If I google for "IE market share" - the first hit I get is
http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0,
which states IE8 as having 22% share (not sure how they generate these stats
as that seems nut ;)) IF I go for the 2nd hit
(http://www.w3counter.com/globalstats.php), that shows chrome with 20% etc,
IE9 6.5%, IE11 5.6%, and IE8 4%
My understanding is bootstrap 3 would support IE 8 for *most* things, and
that jquery 2.x does not support IE8 - hence my point about breaking the PR
up a bit, and also it needing to have a discussion.
The other part is ensuring that we map design changes to something that is
flexible for as many existing users to use and fit into their existing setup
as possible. The new layout would look great for a service (like mantishub),
it may not look as good for people that are trying to top/tail it to use it
in existing environments. We need to ensure that our approach provides
flexibility for both - this is something that mantis arguably does well for
other things due to our complexity of configuration options.
Paul
-----Original Message-----
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI
Paul,
it seems your main concern is using Bootstrap
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.
I can't contribute that much to this decision as I have no own experience
using Bootstrap or any other comparable component.
I don't want to vote just because I read a few articles and comparisons
about it.
What I noticed is a big amount of transferred CSS and JavaScript compared to
the current version. (about additional 700KB when opening for the first
time, but also more traffic for following requests)
Are there any known issues using Bootstrap?
Roland
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their own
custom functionality.
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for
everything.
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages as
necessary.
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based on
the 1.3 plan.
We agreed to ship 1.3 first so…
When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around
whether to use bootstrap.
Paul
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for MantisBT
itself.
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than just
being negative.
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two probably go
together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need to
decide what works best long term.
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an easy win
for end users and plugin author’s for styling.
[Victor]
+ If you scan both bootstrap & foundation docs, you will see the same
features, similar markup and same web components.
+ Bootstrap has a much bigger ecosystem. It came first and was backed by
twitter. It captured developers mindshare early on and became the de-facto
http://techcrunch.com/2013/07/28/bootstrap-3-goes-mobile-first-now-reportedly-powers-1-of-the-web/
http://blog.meanpath.com/4-7m-sites-using-bootstrap-vs-334k-on-foundation/
As such, bootstrap has the lion share of docs, plugins, free and commercial
themes (like the one used with Mantis) … etc
+ Other than that, it is hard to differentiate between both frameworks. Here
http://blog.teamtreehouse.com/use-bootstrap-or-foundation
What about JQuery Mobile?
It is a great framework for building mobile user interfaces. I started using
it when it was in early alpha and was a big fan. That’s until Bootstrap v3.0
came along. Bootstrap v3 is far superior framework for building responsive
interfaces that works on desktop, tablet and mobile.
What about Theme Roller?
That’s not a framework. It is a feature available in jqueryui.com to allow
users to customize the look and feel of jqueryui components. The output of
the theme roller is a custom css file to apply alongside the core jqueryui
library. If you want the same for mantis, you need to build it. It won’t
matter if the underlying framework is Bootstrap or Foundation.
So far, the works been done by someone that has never done a commit to
mantis before
There is always a first time
The new layout would look great for a service (like mantis hub),
Nothing in this work was customized for MantisHub.
The sidebar design is increasingly popular choice (Github, Jira, BitBucket)
because of the popularity of widescreen monitors. With widescreen, you have
more horizontal space to work with and less vertical space. Using vertical
space to show a navigation menu with 5 links is just a waste of precious
user work area.
-Rafik
My main concern is that we evaluate options properly - any decision we take
now is something that the whole dev-team and any plugin author will be
using.
So far, the works been done by someone that has never done a commit to
mantis before - whilst it's fairly clear that they are not stupid, at the
same time, there's historical decisions and historical roadmap items and
plans etc that may not have been considered. It may be that after this work,
we never see the author again. Our published contribution guidelines state
to talk to the dev list first etc etc etc.
Hopefully Rafik will submit a PR with whitespace tidied up and splitting out
some of the non-design changes (i.e. jquery) so we can actually have a
proper look at the work, but there's decisions in that PR that we've already
discussed and decided on a path 'for now'.
For example,
In october 2013 Victor send a mail about upgrading JQuery from 1.7.2 to 1.9
or 2.0
Robert replied stating that moving to 2.0 would rule out IE8
Etc
I replied with what I deemed a favourite question: "what browsers do *we
support*? :)"
A Mantis user replied to the converstation stating about being careful about
browser support as they only have IE8
Robert replied stating IE8 is here to stay.
I might have got the order slightly wrong in the above, but the end outcome
I believe was we updated master from jquery 1.7.2 to 1.9.1
If I google for "IE market share" - the first hit I get is
http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0,
which states IE8 as having 22% share (not sure how they generate these stats
as that seems nut ;)) IF I go for the 2nd hit
(http://www.w3counter.com/globalstats.php), that shows chrome with 20% etc,
IE9 6.5%, IE11 5.6%, and IE8 4%
My understanding is bootstrap 3 would support IE 8 for *most* things, and
that jquery 2.x does not support IE8 - hence my point about breaking the PR
up a bit, and also it needing to have a discussion.
The other part is ensuring that we map design changes to something that is
flexible for as many existing users to use and fit into their existing setup
as possible. The new layout would look great for a service (like mantishub),
it may not look as good for people that are trying to top/tail it to use it
in existing environments. We need to ensure that our approach provides
flexibility for both - this is something that mantis arguably does well for
other things due to our complexity of configuration options.
Paul
-----Original Message-----
Sent: 18 August 2014 21:01
To: developer discussions; Paul Richards
Subject: Re: [mantisbt-dev] Introducing MantisBT Modern UI
Paul,
it seems your main concern is using Bootstrap
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And that’s aside from the fact that we need to have a discussion
around whether to use bootstrap.
Let's start the discussion and get a decision: Use Bootstrap or not.
I can't contribute that much to this decision as I have no own experience
using Bootstrap or any other comparable component.
I don't want to vote just because I read a few articles and comparisons
about it.
What I noticed is a big amount of transferred CSS and JavaScript compared to
the current version. (about additional 700KB when opening for the first
time, but also more traffic for following requests)
Are there any known issues using Bootstrap?
Roland
Paul,
Rafiq,
As i’ve seen on the PR, and when you originally said you were looking
at this a month ago, and asked you to mail the Mailing List, we need
to have a discussion about the design and the approach.
[Victor] Correct. The request from you when Rafik sent out a preview
was to publish the code and the discussion to the DL, which he just
did. Your words were that even though the decision to use bootstrap
is likely to be a short discussion, it is worth having anything.
[Victor] The bootstrap decision really started when the website was
developed. At this time, bootstrap was used and the request by the
team from the Rafik was to do the same modernization to MantisBT.
Hence, he started doing the work. As for plugins, they are typically
easy to adapt to whatever framework MantisBT is using.
Actually, I said we should have a be having a discussion on the
"Whilst I suspect that is probably a good choice, we should have been
having a discussion on whether bootstrap is the way to go with Mantis
or something else before writing any code.”
We set a policy in january that before we accept any external library
changes etc, we need to have a discussion on the mailing list.
And sorry, the website was something that was also done without
discussion initially - so that’s not really a valid point. The website
has always been a separate code base to Mantis.
One of the main requests from users in the past, is that users want
slightly different thing’s - i.e. people want to be able to customise
the look and feel of mantis in different ways.
[Victor] I’m not personally in favor of too much customization to the UI.
In my opinion, a lot of the users that heavilty themed Mantis in the
past were motivated to improve the look. However, what we really need
to focus on is the ability for users to continue to be able to extend
MantisBT via plugins. If we get into theming, we can support color
shade (e.g. green template, blue template, etc) rather than complete
customization. Complete customization adds little value and can
significantly increase complexity of code and test matrix. I believe
users evaluate MantisBT evalute it based on functionalty, look, and
extensions to fill gaps that we don’t have in core or integrate their own
custom functionality.
We’ve had a lot of questions over the years to allow alteration of
bits of Mantis. What we’ve always done is been flexible with the
approach - hence the fact today we have configuration variables for
everything.
If you consider the design of Mantis and the number of pages, we have
a) header
b) menu bar
b) page content -> view issue
c) page content -> view issues
d) page content -> report issue
e) page content -> my view page
f) footer
When people have gone in the past “it should be possible to
template/theme whole of mantis’, personally - I can’t see people doing
that, or it being sustainable for us.
However, I can see companies that want to brand mantis replacing A+F
in the list above, and potentially B
In terms of B/C/D/E - I suspect you would not touch the design of C/E,
but the ability to tweak B+D is where most drivers come from.
For example, I scrapped the report issues page at work a long term ago
as it was not suitable for non-technical users. And within Mantis at
the time, the flexibility we provide for customising it does not
exist. This is actually one block of Mantis where i’d agree with the
people wanting support for templates.
View Issue I didn’t touch as it’s mainly technical staff that use it,
however if the ability existed to template it properly, would be tweaked.
In it’s current form, this PR isn’t suitable for this - For example -
whilst it’s nicer, the reason I use mantis is due to the way it can be
integrated into other systems - so the side bar is a no go.
[Victor] I’m not sure what you mean by integrating MantisBT in other
systems and why the side bar blocks that?
Mantis has always been a top down design - if you replace the
header/footer you can embed the remaining content within another page,
leaving the menu at the top for navigation.
1) My View Page
2) View Issues Page
3) Report Issues Page
4) View Issue Page
I think we can do a better job then the current theme if we focus on
looking at the design and the ability to customise these 4 pages.
For example, in a modern system, the “My View” page I would have
expect to be a ajax dashboard.
I sent an email a few weeks ago now for feedback on using DataTables
to ajaxify the View Issues list.
[Victor] This is just a scoping exercise. The first iteration’s goal
is to improve the look and use a more modern code styling. Once this
is in, we can follow up by enriching specific page to make it use
ajax. Good examples are “My View” and filter page. Once Rafik’s
change is checked in, we can all collaborate on enriching specific pages as
necessary.
For 3/4, the requests tend to be to allow fields to be re-ordered,
turned on/off.
At the moment, the work doesn’t help any of these requests from users.
[Victor] Agreed on these features, but think of Rafik’s change as a
foundation work for these features. I don’t see how there is a
conflict between these features and styling of pages.
Whilst I did try to have a look at the Pull Request, there seems to be
a number of Whitespace changes, and non-theme/design changes that make
it impossible to review the patches.
[Victor] I agree that the change has some white spacing issues that
cause more changes than actually needed. Maybe Rafik can explore of
this issue can be fixed with reasonable effort.
Back in January, we agreed as a Team to get 1.3 shipped, and then look
at UI and email notifications changes. Victor knows I’ve got some work
on templating emails and pages within Mantis from back then, which I
said I’d get a PR up for once the Database changes had been done -
which we agreed as a team to do immediately after 1.3. So until we’ve
done this, compared the two approaches and decide which route we want
to go, i’m strongly against this getting merged.
[Victor] Here is a case where you also have gone and implemented some
change without discussion with the team. At that point I had
discussed email templating (not UI tempting) and proposed an approach,
some previews, and you complained and stopped the work. I’ve asked
you then to share your code / approach and you haven’t. You just
killed the momentum and said that you will publish your code by end of
January then after 1.3. At that point we also agreed that code that
is not published doesn’t exist and can’t be used to block other work.
Rafik has shared a preview of this work with the team 1-2 month ago
and everyone except you on the core team was excited and gave him UI
level feedback which he addressed. So, I expect this code to be
merged. The discussion is when exactly it is going to be merged based on
the 1.3 plan.
We agreed to ship 1.3 first so…
When rafiq shared a preview with people 1-2 months ago was when i
a) we should be discussing this on the dev list.
b) we need to have a discussion on whether to go with bootstrap.
c) I believe I said in the same post, we need to have a discussion on
sidebar on the dev list.
It’s really disappointing actually for me that Rafik has refused for 2
months to email the development list as it’s not enabled a discussion
to take place properly. I think I said in the same email that I quite
liked the design.
Rafik is someone that’s never contributed to Mantis before, has never
been introduced to us apart from dumping a website re-design and now
has added a
10,000 line commit, which is basically impossible to review.
My purpose for asking him to communicate with the development list 2
months ago was so that we could have a discussion at an EARLY stage.
As it is, until we get a PR that doesn’t contain X000 lines of
incorrect whitespace changes in the first commit, it’s actually
impossible to even attempt to review and look at what has been done.
And that’s aside from the fact that we need to have a discussion around
whether to use bootstrap.
Paul
Paul,
Alain,
It’s even more painful, when it’s a big change, and changes the
approach we go in Mantis - hasn’t been discussed on the mailing
list, and there’s work in progress (well, on hold until after 1.3)
to allow greater flexibility of theming mantis already. We agreed
[Victor] When Rafik contributed the new website in January, he was
asked by several on the team to help out with doing the same for MantisBT
itself.
Hence, his contribution. He has used Bootstrap on the website and
carried that forward to MantisBT itself. Given that he has followed
through with this and put this hard word, I would expect that we
would motivate him for that and appreciate the good work, rather than just
being negative.
Now, in terms of Rafiq’s work, I don’t necessarily see it as being a
major problem (i.e. that we’ve got other work on theming) as I think
it covers two different things - i.e. Rafiq’s trying to do a visual
design, anything I’ve looked at tends to be working on allowing
flexibility/functionality rather then visual effects, so the two probably go
together in the end.
[Victor] Exactly, the visual design is orthogonal to allows users to
extend MantisBT through plugins. The believe Rafik’s suggested
change was focused on revamping the visual design for all features.
But to scope the change, it doesn’t try to go further than that.
Once it is in, we can add more flexibility and modernize further.
My main issue is we have plugin’s that add functionality, there’s
multiple CSS frameworks out there now - Jquery UI, foundation,
bootstrap etc, that we do need to consider our approach within
Mantis. I’m pretty confident we could make a similar style using
query ui, foundation or bootstrap - without two much work, so we need to
decide what works best long term.
[Victor] Bootstrap is a very popular and respected library. I think
given that we have this used in the website and the proposed pull
request now, I don’t see why we would go for something else.
Bootstrap also provides a good story for responive design allowing
us to have great native support for phones over time.
The reason I started looking at using Jquery UI in the past (we
actually moved the Jquery UI javascript from a plugin to the Mantis
Core) was due to it being used by some plugins, and having the
visual theme roller - which struck me as something that would allow
an end user without HTML or CSS experience to brand Mantis into
their company colours without very much work. Given that Mantis has
found a whole bunch of uses - for both software development and
non-software development workflows, this struck me originally as an easy win
for end users and plugin author’s for styling.
[Victor]