Feature Requests

We support our internal teams in takeda to create SEI collections. I am wondering why for already delivered SEI collection and Collection admin , we do not provide more autonomy in regards of adding/removing people to and from given SEI collection. That concept of self organization / delegation is very efficient. We receive lots of requests "please add me to this or that collection" and that is painful to manage centrally.

Provide more information in the audit log, such as what areas were changed. This will help better track collection configurations and insights.

Today in SEI, the efficiency dashboard only provides a summary and not a list of individual tickets. In SEI 1.0, this is available The purpose of having this is to understand whether there is data gaps between 1.0 and 2.0 or with internal systems.

In SEI 2.0, we would like to see the available JIRA statuses, not just the hardcoded ones. The problem with hardcoded statuses is that we do not have any data for 'Planning' phases because the required status is not available. Otherwise, the data does not align to customer internal data.

In multi-tool environments, a single developer often appears under multiple identities across systems (for example, different email IDs or username variations in Jira, GitHub, SCMs, or CI tools). Today, SEI primarily relies on a single canonical identity (often sourced from the Developer CSV or a primary system). This results in fragmented attribution, partial metrics, and inaccurate developer- and team-level insights when additional identities are not automatically reconciled. Example Scenario A developer is configured in SEI with abc@PQR.com , but appears as ab@xyz.com in GitHub and ab@gmail.com in Jira. As a result, work is split across multiple “developers,” leading to incomplete productivity, flow, and delivery metrics. Proposed Change Introduce heuristic-based auto identity discovery during ingestion and processing, to automatically map multiple identities to a single logical developer in SEI. Key Capabilities Heuristic-Based Identity Matching Apply configurable heuristics during ingestion, such as: Name similarity (exact, fuzzy, normalized) Username patterns Email local-part similarity Historical co-occurrence across systems (PR author, commit author, Jira assignee/reporter) Assign a confidence score to each inferred identity match. Confidence-Driven Auto-Merge High-confidence matches are automatically merged into a single developer identity. The canonical developer remains the one defined via Developer CSV (or primary identity source), with additional identities linked as aliases. Admin / Team Manager Review for Low Confidence Matches When confidence falls below a defined threshold: Surface a list of potential identity matches in the UI. Allow SEI Admins or Team Managers to manually confirm, reject, or adjust mappings. Decisions are persisted and reused for future ingestions. Auditability and Control Maintain an audit trail of: Auto-merged identities Manually approved or rejected mappings Provide the ability to unmerge or reassign identities if needed.

Moniepoint has shared a number of wish for metrics that would bring alot of value with regards to the usage and adoption of SEI. Please find these listed below: Sprint Delivery Data Analysis - P1 We would benefit from having insight into team performance. Specifically, calculating the average sprint velocity for each team based on their historical sprint delivery data, ideally looking back over a quarterly period, would be very useful. Work Item Breakdown - P0 To quickly assess workload distribution, we require a visual breakdown of work items per assignee, ideally presented as a pie chart. Epic Estimation: Aligning Timelines with Business Expectations - P2 To enhance business alignment, it is recommended that Epic estimations include projected completion timelines. These timelines should be based on the scope of work and the expected frequency and velocity of execution. Merge Request Comment Metric - P0 Filter out comments from AI bot comments on PR using the user_id. This should not be taken into account for the number of comments and time to first comment. Merge Request Contribution Metrics - P1 Track MR contribution as an interaction-view to show which team members review each other's MRs. The goal is to understand key man risk, burdened reviews and members who don't assist in reviews. Work allocation - P3 Break down per team member to understand where they spend their time using FTE: Writing Code, Reviewing MRs, Meetings (integration with GMail) Meeting time - P3 Metrics to track how much time is spent by the team in meetings. Benchmarking - P2 We would like to, at the project level, define the single team against which all other teams are benchmarked. This should show on all graphs.

In SEI 2.0, you cannot change the structure of an existing configured organisation tree. The only option is to create a new tree, but doing so will require reconfiguring the settings, adding manual effort, and causing unnecessary toil for the customer.

As an Engineering Organization, we would like to integrate the Wiki platform with Harness to monitor metrics for some of our teams. This integration will enable us to track activities related to document creation and updates effectively. We use Atlassian Confluence as our internal Wiki platform. Your insights or suggestions on implementing this would be greatly appreciated.

Request to enhance the TestRail Integration widget in Harness by adding time-based filtering options. he primary goal is to support filtering test cases based on: Created On / Created By - Filter test cases added during a specific timeframe or by specific users Updated On / Updated By - Filter recently modified test cases or identify contributor

Surface a way to query TeamRefId programmatically to make team level report queries surface the api(s) involved in extraction of developer/contributer info + raw_stats enable retrieval of this section depicted in the attached image programmatically We would like this part of the api to be surfaced in v1 and v2. The likely endpoint: POST /gateway/sei/api/v1/dev_productivity/reports/fixed_intervals/raw_stats/org/users?