User Details
- User Since
- Nov 3 2015, 9:16 PM (472 w, 1 d)
- Availability
- Available
May 31 2017
Mar 15 2017
@jaufrecht My pleasure. In general, using color gradients or shades is fine (and, actually, pretty much standard) for emphasizing trends. However, I would expect a use of gradients or shade of a single color to visualize a trend of a single category (topic, subject). In your case, though, the image presents trends in that fashion for multiple categories, which makes them difficult to distinguish and track. I would prefer and suggest using different colors for different categories and using a particular color's gradients or shades for each category across the time. Does it make sense to you?
@jaufrecht Nice description. A quick comment on the attached image. Please take no offense, but IMHO, from the UX / usability perspective, this approach (using the same color's gradient or, in your case, shades) is pretty terrible and, as far as I know, is recommended against as the data visualization best practice. Hope this helps.
Oct 21 2016
@iamvoid I think that you don't really understand the meaning of the term "onboarding" - it refers to a process that occurs after evaluation. Thus, you comment doesn't make sense, in my opinion. Any quality product or project should have a solid documentation, including parts, covering an onboarding process. The existence of the document above supports my argument.
Sep 3 2016
No problem and you're welcome.
Apr 14 2016
@chad Thank you for the comments and taking care of my request. But to reply to your (hopefully, not rhetorical :-) question on why the inverse statement is not true, it is IMHO quite simple: similarly to having any book's table of contents (ToC) in the beginning is natural, any long enough document will benefit from having its hierarchy (essentially, a ToC) placed prior to the main level content. An unlikely potential confusion might be further eliminated by adding an anchor hyperlink to the beginning of the said content as a part of the document structure.
Apr 13 2016
Mar 21 2016
Thank you both for clarifications. Will follow your advice.
@richardvanvelzen Thank you for your comment. However, I don't have /config/module/versions/ or any Phabricator-related versions file or directory, for that matter, on my system. If you meant /conf/, then this directory contains only the files __init_conf__.php, keys and local. Please clarify.
Mar 6 2016
@chad Got it - thank you. Sorry I missed that comment.
@chad Thank you for the clarification and the link. That mockup looks pretty good to me (though I couldn't decode the implied functionality of the "+" icon in the left top corner of the area (to the left of "Add Action"). Also, I'm not sure that forcing people to select the preview tab is the optimal choice - not only it's an extra click each time, but also doesn't give the user an idea about the fit / layout of the text in a horizontal dimension. Just my two cents.
@epriestley @chad [This comment is not specific to the above-mentioned changes, but rather general.]
Feb 28 2016
The onboarding would be much easier, if Phabricator would offer a clear and detailed single document, describing and explaining the full Phabricator-based development process (along with rationale, advantages and disadvantages at each step). Something similar to this nice post, but more clear and more comprehensive.
Feb 21 2016
@ProfFan My pleasure! :-) Thank you for the link - will take a look.
@ProfFan Great job! Thank you for your efforts. BTW, what is Celerity?
Feb 20 2016
@epriestley Thank you for clarifications and links. By the way, does current version of Phabricator support arbitrary depth for wiki pages hierarchy? Could you refer me to the relevant information? Thank you in advance.
Feb 19 2016
Feb 15 2016
@avivey Sure, you're right. Thanks!
This task can be closed as Resolved.
Feb 14 2016
Feb 7 2016
@epriestley I have noticed that, in your first comment above, two links, titled "in this document", are broken (links are located in sections "Branching" and "Merging"). It would be nice to have those links to presumably useful and important documents fixed.
@chad Yes, I ran across it recently. However, it's not clear to me, whether Phragile offers more comprehensive Agile functionality than the Sprint extension, or it is just a repackaged original extension with a more independent installation.
@epriestley I think you're slightly exaggerating the complexity of my suggestion. Anyway, this is my first acquaintance with reporting/charting functionality in Phabricator, so I will take time to read more about it (via the task you've linked and beyond). Since you're online, could you give me a pointer to info (beyond Harbormaster documentation), perhaps an article, which describes an end-to-end process of building a CI implementation without external CI servers, such as Jenkins (of course, if it's possible at the present time)?
@chad Yes, that was my implied suggestion. Thank you for clarification. Perhaps, I need to take another look at the Wikimedia's Sprint extension (I'm trying to minimize dependencies on external Phabricator add-ons).
@chad I don't see how this fact affects my suggestions. When calculating progress indicators, this simply means that those indicators should reflect corresponding projections (which tasks belong to which projects).
I think that there should be a single progress bar per project (sub-project), where what metrics (story points, days, ...) are used to produce the corresponding chart should be user/admin-configurable on an individual project (sub-project) basis. That way, both single-metric and more comprehensive multi-metric charts are possible, based on projects' specifics and users' preferences.
Jan 28 2016
Jan 27 2016
@chr86: Yes, I was able to solve this a while ago. If I remember correctly, I have just used the following instructions and, perhaps, restarted the server once or twice: https://secure.phabricator.com/book/phabricator/article/notifications. Hope this helps. I think I wrote down the solution steps, but couldn't find that document at the moment (maybe I didn't write anything down) - please let me know, if you are successful in that.
Is it currently possible to configure number of levels to be displayed for wiki document hierarchy in Phriction? The current default seems to be equal to '2'. I have seen D8061: Show configurable level in the Document Hierarchy in Phriction., which is not resolved. Perhaps, I have missed other relevant info.
Jan 21 2016
@chad Thank you for quick clarification.
@spicyj Good idea, thank you for the advice :-). I just wasn't sure this feature is in production...
How do I get this feature? System update? If Yes, please point me to documentation, describing the update process. Thank you!
Dec 17 2015
@nnnn20430: I see, thank you for clarification. I will give that a try.
Dec 16 2015
@nnnn20430: Thank you for the reference. Did you apply the patch, included in T9293: WebSockets access problems with reverse SSL proxy ?
Nov 23 2015
@avivey: Thank you for clarification and references. I understand the rationale behind the changes, though, I still see that Phabricator still allows executing "trusted" binaries (whatever it means). Anyway, I could not find documentation on using extensions, so I'm not too sure about how to use tex2im, tex2png or similar programs in Phabricator's context. Perhaps, someone could point me to the relevant documentation and/or, better, share some examples for that approach.
After reading the Contributing Code guide, it seems that I would have quite a high barrier of entry, should I decide to contribute to the project on this feature (upstream; normal process). In regard to listed alternatives, local fork is likely not a good idea for me and developing an application is likely not relevant to this feature, as, if I understand correctly, it should be a part of general/core code (i.e, Remarkup blocks for wiki). Therefore, the only feasible option (for enabling this feature on local install) that I could think of (additional benefit: this would be general, enabling LaTeX for any Phabricator's Web output) is to move the LaTeX-to-HTML on-the-fly conversion outside of Phabricator's code, specifically, as part of Web server request processing. For example, it could be implemented as a Nginx module or directly - via Nginx config - pass the output through KaTeX's server-side processing ("Server side rendering: KaTeX produces the same output regardless of browser or environment, so you can pre-render expressions using Node.js and send them as plain HTML."). Does it make sense? Please let me know what you think about all this.
@chad: Got it, thank you for the reference!
New kid on the Phabricator block here. Firstly, I just wanted to say that I thoroughly impressed by Phabricator and thank all of contributors you for producing such a nice piece of software. After rather comprehensive evaluation of existing tools (mostly open source), I have chosen Phabricator as a platform of choice for my initiatives on improvement of research and software engineering processes a materials science / materials informatics research group, where I currently work (Georgia Tech).