@ksmith it's a Python script that you would run on your local machine. If you have arcanist setup for development it should be pretty simple to get it working. Ideally it would just be a plugin, but I didn't look into that approach yet.

@lyahdav : That looks pretty cool. It's not quite clear to me where it runs. Is this a script that one would install on the same box that phab itself is running on?

For anyone trying to get Kanban statistics / reports in the meantime, you can try this project I recently started working on:
https://github.com/lyahdav/analytics-limn-analytics-data/tree/kanban_stats. It generates a CFD (Cumulative Flow Diagram) and computes cycle time and lead time.

@dserafin - For something in the meanwhile, this is what I do to get reports:

1. Added custom field(s) to Maniphest Tasks to classify task type - see Configuring Custom Fields
2. Install extension for exporting Maniphest Task search results to Excel spreadsheet
   • This requires PHPexcel to be installed on the machine, and for your php.ini to be configured to load that library.
   • The extension can be downloaded here (use at your own risk) - this adds some columns to the output to include some custom fields -- not all field types have been tested/implemented. If the task is on a project workboard, it will also list the workboard columns it's on. The code is fairly straightforward so you should be able to modify as-needed.
     • https://github.com/neandrake/phab-utils/tree/master/extensions
3. From web interface do a search query for tasks, then at bottom select Export to Excel, then select the 'Default with Custom Fields' option.

As cspeckmim, I'm working in a company where all code is safety related and must be certified. We'd like to have a report on the code review activity. At present we have to submit a lot of screenshots to demonstrate we performed code review using Phabricator...

I'm just going to close this out since I think it's mostly superseded by T5307, which discusses this and other actions which would be nice to take with query result sets.

We may have some support for this after T1562, but probably will never have sufficiently granular upstream support to solve this particular problem. I don't anticipate ever disclosing who cloned things in a web-accessible way.

Yeah, I'm mostly concerned about future changes (offhand: phone numbers, emails, messenger handles, oncall schedules, events/availability).

If there is a reasonable path forward that @epriestley will approve, I can do the grunt work and close this out.

Philosophically I'm fine making People "public". The main reason for me is that all the information on a Profile is already (in the most common cases) exposed in other "public" areas of the product (like hovercards). I do think though that when an install is public, we should have an additional reminder/note when someone goes to edit their profile as a reminder. With public profiles, I think we also need to be mindful of upcoming apps like oncall schedules, where some information might be actually private (and thus displayed in that individual app, like Calendar can) and not randomly exposed.

D13024 fixes this for Owners.

In T4830#74187, @epriestley wrote:

(@btrahan, you're the only repro I have, so don't change your profile picture!)

We unfortunately have no means of predicting features for things we're not intending to build for many years. If your company has needs for these things, please don't rely on Phabricator and choose a product that offers the features you need now.

e

eqee

3424234

In the industry I work in, we require documentation surrounding our code quality, specifically documented code reviews/audits (currently this is all done on paper). These tasks regarding reports/metrics/data seem like it would be a good place to mention our use case in hopes that it's considered during design & development.

That's right. Even if someone somehow built exactly what we plan to build (which would be effectively impossible since we aren't totally sure yet ourselves and it definitely doesn't exist as a written implementation plan anywhere), we wouldn't have the time to review, integrate, and support it right now, so it would just sit in limbo until we got around to prioritizing these things.

Just to confirm (and I'm not trying to be cynical!), you are saying that you are not planning to work on this any time soon, and you don't encourage others to try either, right? If this is the case, perhaps the best option for us will be to try to find a shorter term solution poking the Conduit API and creating the metrics outside, as we are doing at http://korma.wmflabs.org

Only a small amount of work has been completed here. We don't have implementable plans for the remaining work yet.

What is missing in order to consider this task done?

Sorry, we don't provide reports at this time. The main issue here being only a very small number of installs want some sort of specialized report and none of them want the same type of report. Facts will eventually provide a data framework in Phabricator, but it is not on any immediate roadmap.

I'm going to merge this into T4171, since there's nothing specifically actionable here that isn't covered there.

Add one more:

We are trying to find an standard way to do some member performance elevation and do want to use PHABRICATOR in whole development cycle including performance elevation as it can provides data. All below metrics I want to by member.

I merged this back to the parent task T6041 (which is really just use cases motivating T1562 and not directly actionable.)

Examples of use are always helpful.

Understood. Since I cannot help coding tools that let us build charts, I thought that defining specific metrics could help you coding them. However, I don't want to create tasks that don't belong here. Just tell me if this feedback is useful, and how you prefer to get it. No problem if the answer is 'no thanks'. :)

Almost all of the planned work here is in building general infrastructure. We don't plan to build charts, we're going to build tools that let you build charts. The upstream goal here is to avoid a dynamic where installs ask us for everything they want a chart of and we're stuck maintaining a large number of hard-coded ad-hoc charts. Assuming we do a good job of building tooling, we'll end up in a state that's better for everyone: you'll be able to build your own charts (by selecting what data to chart, configuring the chart, and then embedding the chart in other objects), and we will just be maintaing a relatively small and simple piece of infrastructure, which is actually large and complex, but simple when compared to the cost of maintaining hundreds of ad-hoc charts.

If you needed a real use-case now we have one: T6041: Metrics for Maniphest. Your feedback is welcome.

I also have learned that the custom avatars in Recent Activity will not be shown to anonymous users either

... and now we have a real use case where the lack of public user profiles affects us.

Some discussion in T5873 of better API access to this stuff, but we don't ever plan to support this specifically.