Hi,
First off, thanks Mikel - great improvements on the history tab.
On Sat, May 7, 2011 at 3:33 PM, Mikel Maron mikel_ma...@yahoo.com wrote:
[..]
In the bigger picture
* The real way to deal with big and bot changesets is to have this listing
driving by OWL. What's needed to make that
Hi
Who's interested in working to improve the usability of the History tab? What
do
you want to code?
I've started coding some improvements in the History Tab -- you'll notice a new
map.
Described a bit on my blog, http://brainoff.com/weblog/2011/05/05/1674
There are already some obvious
On 07/05/11 14:33, Mikel Maron wrote:
* big changesets are no longer marked, but that was useful. Want to
find some non-obtrusive way of visually distinguishing them.
* would be nice to do a similar same thing with bots. Is there a bot
flag in the db?
The correct solution to this is to sort
On 07/05/11 15:24, Mikel Maron wrote:
I'm not talking about filtering them, I understand the issue. Rather,
simply visually distinguishing them. We had that before the last update.
Is it actually useful though? What does it tell you? What do you
differently when you know it is big for
On 07/05/11 16:04, Mikel Maron wrote:
Totally useful. Was an easy way to ignore things that were possibly
irrelevant. Bot might accomplish the same thing.
That's easy - to a first approximation *all* the changesets in the
browse list will be large unless you are looking at an individual
On 07/05/11 16:12, Mikel Maron wrote:
In this case, we're just talking about if this is a good usability
feature, or not. To me it's good, was good, and now it's less usable in
a way than before.
I have never found any use for the big changeset indication that was
there before, other than to
On 07/05/11 16:26, Ian Dees wrote:
Why is filtering off the table? Just don't output the items that have
big marked. Sure we still have to use CPU time to determine the size
of the bbox, but we're already doing that. Equal CPU time for a possible
improvement to user experience seems fine to me.
On 7 May 2011 16:18, Tom Hughes t...@compton.nu wrote:
I don't see the point of distinguishing big edits because people don't
really care - the only thing they really case about is whether the edit
touches a given area. Big is simply a (poor) proxy for that.
You've touched on something here
On Sat, May 7, 2011 at 10:29 AM, Tom Hughes t...@compton.nu wrote:
On 07/05/11 16:26, Ian Dees wrote:
Why is filtering off the table? Just don't output the items that have
big marked. Sure we still have to use CPU time to determine the size
of the bbox, but we're already doing that. Equal
I have refused to apply patches which do that, because I want somebody to fix
it properly and I am trying to incentivise people to do so.
Tom, you're talking about integrating OWL, yes? And in principle, that's the
best solution ... but it's been over a year that I've heard that, and I just
On 07/05/11 16:39, Ian Dees wrote:
It appears that OWL is the way forward then. Will you allow patches that
use OWL's API to request history or will that fall under no external
services? Presumably when OWL gets real hardware it will be a different
machine but on the same network.
There's no
On Sat, May 7, 2011 at 5:46 PM, Mikel Maron mikel_ma...@yahoo.com wrote:
I have refused to apply patches which do that, because I want somebody to
fix it properly and I am trying to incentivise people to do so.
Tom, you're talking about integrating OWL, yes? And in principle, that's the
best
On 07/05/11 19:58, Erik Johansson wrote:
Even if OWL gets integrated I think Mikels solution would still be
better for many changesets (and vice versa). Considering that OWL in
its current form isn't designed to visualize lots of changesets, this
clearly isn't only about big changesets.
I
13 matches
Mail list logo
