Well we also have a lunch today.

We could probably ship it (.md in Diffusion rendering as GitHub Flavored Markdown) this week -- it wouldn't be perfect, but we do have total freedom there to iterate as we find cases we're missing there -- it's just a pretty hard sell as a priority for me relative to the development cost. Obviously it would be nice if you bring in your repository to Phabricator and the README.md renders perfectly instead of rendering mostly-okay-but-a-bit-buggy, but it's hard for me to imagine we're losing many users there.

Having markdown rendered in documentation as expected probably alleviates 90% of my concerns. At least, having to retype or reformat large chunks of text is un-cool and arduous. Learning some new markup, less so. But it sounds like thats years away.

My anecdote here is Betamax vs. VHS. Yes, one is superior, the other has 95% of the market. I believe we're both right, but weigh certain issues differently. I see the new user coming from GitHub as the more important customer, as it leads to growth. The more things are different in Phabricator, the steeper the climb. You're right from a technical standpoint, and I do believe Remarkup is superior, so I'm stuck.

I think the two goals are sufficiently in conflict and the value of supporting these rules is so low that it probably isn't worth the effort to try to get it right most of the time.

Maybe a different question is, what percentage of block of Remarkup here include code-related discussions. I'm not saying rendering those well shouldn't be a high-priority, I just see Remarkup used for much much more (task discussions, documents, conpherence, etc).

Are you strictly saying both goals here are not attainable?

I can confirm that In Any: does not seem to include subprojects. I tried to make some sense of the way the project search functions work but it's pretty complicated.

My viewpoint is that Markdown was developed for writing first-party blog posts, not for technical discussions about software.

Just going to reopen this as a wishlist item. Italics/Bold here is probably the biggest requests for cross-functionality Remarkup <-> Markdown I'd personally have. And at least in your test cases, it seems even GitHub fails at them (and CommonMark), though Slack does not, so I think these are workable in the general sense, just will likely come with lost of test cases and regex support. I think correctness of expectation is your main concern (and the maintenance cost), not adhering to a "spec"?

Oh, sorry! I totally missed the bit with italics which described things quite precisely.

After updating the task a million times I did reduce the reproduction steps to just not having the user in the Default View Policy (presumably at time of creation the creator is not in the Subscribers policy group explaining the others' scenarios). I had updated the description to note that but I chould've made that much more clear. Spaces were totally a red herring.

@cspeckmim I think that patch fixes the issue, thanks for hunting down those reproduction steps!

I haven't seen more of this and there's no planned action on our end, so I'm going to presume we've weathered the storm.

I'm going to fix the bug with these reproduction instructions:

In T12369#216517, @rall0r wrote:

I even get the same error every time creating a new task.
It seems related to Maniphest Policies.
Our Maniphest Policies are:

What solves the problem is setting Default View Policy and Default Edit Policy to All Users.
Hope that helps.

I even get the same error every time creating a new task.
It seems related to Maniphest Policies.
Our Maniphest Policies are:

In T12441#216428, @epriestley wrote:

If there's any good content in this feature at all, why do I never see it reposted to Reddit or Facebook or Twitter? Are Reddit and Twitter just for old people now?

Elasticsearch has much better support for non-latin language analysis. See https://www.elastic.co/guide/en/elasticsearch/guide/current/icu-tokenizer.html discusses their ability to properly tokenize Thai, Chinese and Japanese text.

T12003 is also related to this (providing more explanatory, contextual help for users executing searches which may not be doing what they want for technical reasons).

There's some additional stuff in D17384, where Elastic has an internal hard limit of 10K results.

@beber, please file a new task with reproduction instructions that work on a clean install if you believe you've found a bug.

@phillco - Is this for like, seeing code reviews that haven't had active participation in while? So users could see what's not being reviewed and lend a hand? Under the assumption that the "most-qualified" stakeholders (or Owners?) are already reviewers/subscribers of a code change but aren't being active, how effective would others' review be?

One other thought as a sort of counterpoint to myself: if we do implement T11367, I probably would expect it to work more like "portals", where you define a portal/directory/volume and everything inside it shares the same permissions. But that's because I'd plan to eventually build DefinitelyNotDropbox.app for bridging file directories to the desktop so you could mount the filesystem on your computer as a disk, and I think we get into enormous amounts of trouble if I mount the phacility_tax_documents/ drive locally and then individual files inside it might have individual permissions so I couldn't view or edit some of them, since there's no way we can give users guidance about that from a filesystem mount. But maybe we have more flexibility there than I think.

I think we could just add spaces without any real fuss, yeah. Two possible considerations:

Ok I think this is mostly a UI issue then, and I didn't think this entirely through. Also, spaces then should just work?

I do think we could make a product argument like "the hierarchical permissions system is too complicated for users to understand, and they'd be better off with a less powerful system". That might look like:

(this is a problem for me switching on and off projects, haha, I forget design decisions)

I probably solved most of this with my Phriction redesign which visually treated child pages as navigation.

I think PhrictionPortal probably doesn't look too much different from "make a second wiki, except this time you don't have permission to edit the root document, and it's locked to public / all users visibility automatically, and it's at some other URL other than /w/, and remarkup has two different rules".

Hmmmmm, so this essentially exists but you have to make /w/ public in order to achieve it?

When I create a second portal ("Encyclopedia of Fruit") and a page ("Orange"), what URL does the page exist at?

Yeah, we kind of fake that now by offering an index page on Phriction welcome with major projects being there on "root" level.

I think we should just move Phriction to being a full CMS with different top-level hierarchies, which could be space aware. Just implementing Spaces doesn't make much sense otherwise.

🔥 🔥 🔥

I 😍 love staying in touch with my favorite brands. 🎁

Hmm, I could definitely see "Philters" in the near future! Imagine the sponsorship opportunities to add Branded Comments™ via Phabricator® Philters™.

@epriestley: Yeah, I think the brightness level is off. I got a very dark picture as well, although it wasn't all-black.

In my view, Stories products encourage out-of-band collaboration where the original product falls short. For example Instagram has a "best self forward" impression that causes users to artificially constrain posting. Instagram Stories combats this with its ephemerality and whimsy. It's a "back door" without having to fix the root problems in the main product.

I got the python script working by changing "w" to "wb" like a comment suggested, but I'm only getting all-black bitmaps out of it.

Does anyone actually use the "Stories" feature in one of the other things that implements it (Excel, Settings.app, Disk Recovery Utility, etc)? Why is it compelling?

@epriestley: Evidently imagesnap no longer works on macOS 10.11 "El Capitan":

I think this would be easy as a menu-item, really. Main issue is what criteria to pick for the stories.

That would be revealing whether or not FB has already been internally A/B testing precisely this on engineers.

Do you even have Cat Facts internally yet?

you expect Fb to cherry-pick it?

I view this as a really effective mechanism to ensure timely code review. Don't review my diff within 24 hours? Poof, code is deleted.

The UI should probably look like this (not 100% final/polished yet):

+1

I think pictures are part of a "story"? We can have users upload pictures and take pictures with phones. There doesn't seem to be a native CLI way to get Macbooks to take photos but we can make users brew install imagesnap, it seems, and then arc could update stories.

Hmm. Ok. Deleted.

I'm going to probably re-design this page a little.

Thank you for such a quick turnaround! Highly appreciated.

@epriestley If you just add copy in the selection dialog, it will help a lot IMO:

And that's a really great profile image!

Thanks for the extremely thorough bug report. This should be fixed in HEAD of master, and promote to stable within about 72 hours.

I'd guess there is a ...->setContinueOnMissingFields(true)->... missing on an Editor somewhere.

Actually, that fix is completely bogus and there's no inverse edge type so this is perhaps somewhat more involved.

This is probably a one-line fix, but let me repro + get test coverage on it.

Specifically, this task is about how the javascript in typeaheads rank and match choices.

Not similar.

So root must always be visible to all?