I'm still blocking D8685 for no particular reason, that might be a good place to start. I think grouping the menu up probably makes more sense -- at least as a starting point -- than trying to build a unified object relationship dialog (which feels hard to get right, offhand).

Do you think theres a path to just having a generalized "Object Relationship Dialog", or is that likely too complicated? It'd obviously be nice to compress the action links.

I don't expect this to meaningfully impact performance unless we end up with a really fancy animation when cards fly around.

Can we just change "Select" into two buttons "Blocks" and "Blocking" (or whatever language, those hurt my head)

Can we just change "Select" into two buttons "Blocks" and "Blocking" (or whatever language, those hurt my head)

Quick note, that performance would be my biggest concern as an end-user.
When we were using Trello, it would frequently cause my (firefox) browser to "freeze" for 30-60 seconds at a time, whilst medium to large size boards were loading, and dragging cards around was usually sluggish-feeling. e.g. https://trello.com/b/k5N0ivoM/research-and-data
Versus my experience with Phabricator so far, which has been that medium size boards load quite rapidly, and dragging cards around feels quite responsive. e.g. (1,600+ cards) https://phabricator.wikimedia.org/tag/flow/

Thank you for the quick reply. We'll see.

@chad, do you have any clever design ideas on this? The best thing I can come up with is sticking a dropdown in the dialog, but that feels really clunky and hard to use to me.

I'd guess the simple version (just a "something on this workboard has changed" notification) is about 2 hours of work, and needs to happen first anyway.

Would you be able to give a rough estimate for paid prioritization of this task?

Would you be able to give a rough estimate for paid prioritization of this task?

Mostly we're trying to convey more with less color. These new items take up more space, but color/visual impact should be roughly the same. The blue stands out quite a bit, still.

In T1460#104476, @epriestley wrote:

(At the same time, I hesitate a bit because having the icons up there be totally different for every comment is also weird.)

New inline comments are really awesome overall, though.

(At the same time, I hesitate a bit because having the icons up there be totally different for every comment is also weird.)

Easy enough to do

Easy enough to do

At first actual-real-use, this state feels a little weird to me (the "Not Done", specifically). Maybe we should just hide the checkbox element on drafts, now that we aren't letting you pre-check your own comments?

@csilvers D12171 is the next UI piece to land, once that's polished up we'll look at the comments-table

This feature is a big hit over here at khan academy!

• the left margin of Done checkbox is incorrect, which results in left checkbox edge being cut off
• the vertical align links is incorrect

See some discussion in T7660.

When user have checked "Done" checkbox in inline comment, but haven't used large commenting form at the bottom, then comment end up in fixedState = 'draft' and no indication elsewhere is found:

• after large comment form indicating, that there are drafts
• in the list the yellow speech bubble

After T7149, drag-and-drop uploads support arbitrarily large files and resumable uploads for files larger than the chunk threshold (currently 8MB).

In T5793#101228, @chasemp wrote:

What if the "flags" app had a workboard and you could manage your flagged issues as if you had a personal project. /a crazy thought.

What if the "flags" app had a workboard and you could manage your flagged issues as if you had a personal project. /a crazy thought.

For the actual inline, here's the set of elements I'd like to try starting with:

In T7287#96791, @mholden wrote:

Is upgrading as painless as a "sudo apt-get upgrade mysql" -- or am I asking for huge amounts of trouble with that level of naivete on my production install?

Sorry, I pretty much have no idea.

Is upgrading as painless as a "sudo apt-get upgrade mysql" -- or am I asking for huge amounts of trouble with that level of naivete on my production install?

The simplest fix for this would be to make the pre-5.5 sorting collation utf8_general_ci. Most columns with sort collations have only ASCII text (email addresses, usernames, callsigns) but these do not:

Aaah, okay. Upgrading to MySQL 5.5 or newer and running bin/storage adjust will fix this. I'll look into getting it fixed for older MySQL versions.

./bin/search index --type USER had no effect.

There is also a very small chance that running this will fix it:

Hmm, I'm not sure then. Can you show me the output of this?

And, my head commit is at 5a9d70707b9e16169b8a298135b36dd133e2ae

And, my head commit is at 5a9d70707b9e16169b8a298135b36dd133e2ae

Nope, no adjustments

I updated about to the upstream 2 hours ago, I didn't notice any adjustments when I ran my "update.sh" script.

Just a guess. I actually can't reproduce this, though, at least immediately:

:p So is that a known bug, expected behavior?

I am a master sleuth.

Actually yes, I believe they do

Do all the problematic users have uppercase letters in their names?

It would be a lot simpler to use HTML 5 File API together with a regular <input type=file /> field. This won't help the IE8s of the world, but will help users of non-standard, but modern operating systems and browsers.

Remaining work here is:

Particularly after strengthening the "prototype" barrier, this is more of a "users want it" issue than a "this has high support costs" issue.

We'll want to use the background colors for tags, and maybe with the checkered tag just use a simple grey background.

Projects currently have a small "typeahead/tokenizer" icon (which appears in typeaheads) and a larger "profile picture".

+1 for mobile browsers