ROCm/rocm-libraries - Open Source PR Review Scorecard

super repo for rocm libraries

C-Rank Grade: A (Welcoming) - 64/100

External PR Merge Rate: 8%

Response Time: <1h

First Timer Success: 16%

Frequently Asked Questions

Is ROCm/rocm-libraries welcoming to first-time open-source contributors?

ROCm/rocm-libraries has a recorded first-timer success rate of 15.5%. Repositories ranked A typically provide actionable feedback during code reviews and actively nurture new community contributors.

How fast can I expect code review feedback on my pull request?

Maintainers in ROCm/rocm-libraries respond to incoming external pull requests in approximately 0.5 hours on average. Keeping PRs focused on single tasks and ensuring tests pass helps maintainers review faster.

What does the 63.7 C-Rank™ score (A Tier) represent?

The C-Rank™ system evaluates GitHub projects on a 0–100 scale using real data: PR merge rates, review turnaround time, active maintainer presence, and first-time contributor success. A score of 63.7 places ROCm/rocm-libraries in the A tier.

What is the external contributor pull request merge rate for ROCm/rocm-libraries?

The external contributor pull request merge rate for ROCm/rocm-libraries is 8.4%, based on public PR activity from non-core contributors.

Are there Good First Issues available in ROCm/rocm-libraries?

ROCm/rocm-libraries currently has 7 active issue(s) tagged with beginner-friendly labels like "good first issue", "beginner", or "up-for-grabs".

ROCm
ROCm/rocm-librariesA•Welcoming447
GitHub
Back to Explorer
ROCm

ROCm/rocm-libraries

447
Active (30d)A•Welcoming(64/100)ASAssembly

super repo for rocm libraries

GitHub
Compare••
Jump to:

AI Maintainer Review Guidelines

Review Persona

Active Open-Source Maintainer

Warmth Score
7.8/10
Patience Score
8.2/10
Nitpick Rate
20%

Active maintainer team in ROCm/rocm-libraries welcoming community pull requests and bug fixes.

Top PR Submission Do's

  • •Ensure code complies with repository style conventions
  • •Keep PRs focused and well-documented

Top PR Friction Pitfalls (Don'ts)

  • •Do not submit unlinked PRs without context
  • •Do not break existing automated test suites
Response Velocity
<1 hour
⚡ Fast reviewer response

Average Response Latency

Tracks hours until a maintainer leaves a review, comment, or PR response.

Merge Efficiency
8.4%
Selective PR acceptance rate

External Acceptance Rate

Percentage of community pull requests successfully merged into main.

First-Timer Success
15.5%
Accepts new contributor PRs

First PR Conversion

Rate at which developers submitting their first repository PR succeed.

Active Maintainers
211 core
Highly collaborative maintainer core
Diagnostic Health HUD
8.4%
Merge Gauge
15.5%
1st-Timer
Community Vibe38/100

Embed C-Rank Badge

Show contributors that your repository actively reviews and merges external pull requests.

GetMerged C-Rank badge for ROCm/rocm-libraries
[![GetMerged C-Rank](https://getmerged.abhishekco.de/api/badge/ROCm/rocm-libraries)](https://getmerged.abhishekco.de/ROCm/rocm-libraries?utm_source=github&utm_medium=badge)

Active Good First Issues (5)

View on GitHub

Summary Expose the remaining hipDNN Graph lifecycle, plan-management, inspection, and serialization APIs in the Python bindings. Parent: #10579 Required API Add Python bindings for: build checkTensorUidsSet getTensorsByUid getTensorsByName set_override_shape_enabled is_override_shape_enabled The execution overload accepting runtime shape and stride overrides. to_compiled_plan_binary from_compiled_plan_binary get_execution_plan_count execute_plan_at_index get_workspace_size_plan_at_index get_plan_name_at_index build_plan_at_index get_autotune_workspace_size get_plan_name Use Python-friendly return values for C++ output parameters and preserve optional values and error reporting. The override-shape methods must remain consistent with the existing HIPDNN_ENABLE_SDPA feature guard. Tests Add focused tests for: build and the complete standard graph lifecycle. Tensor UID/name inspection. Plan count, plan selection, plan execution, workspace, and plan-name queries. Compiled-plan serializat

📅 Opened Aug 10, 2026💬 0 comments
Quality: 40/100Contribute

Summary Complete the Python bindings for hipDNN TensorAttributes and scalar tensor metadata. The current binding covers basic dimensions, strides, dtype, UID, name, virtual status, and a float-only set_value. It does not expose the complete public tensor metadata and pass-by-value API needed for full frontend parity or DLPack integration. Parent: #10579 Required API Expose the remaining public tensor metadata methods, including: Scalar tensor construction for all supported value types. get_is_pass_by_value get_pass_by_value get_compile_time_constant get_has_compile_time_constant get_is_runtime_pass_by_value set_as_runtime_parameter set_is_pass_by_value set_compile_time_constant get_value_variant clear_value Ragged-offset getters, setters, and presence checks. Alignment getters and setters. Any remaining public data-type, dimension, stride, output, virtual, UID, and name accessors. Use Python-friendly conversions for C++ scalar variants and optionals. Preserve existing Tensor.create()

📅 Opened Aug 10, 2026💬 5 comments
Quality: 40/100Contribute

Suggestion Description As part of enabling relaxed affine tensor shape requirements for BatchNorm in this PR in hipDNN, the corresponding frontend changes have currently been implemented only for the BatchNorm operation. To fully support this feature across all BatchNorm operations, the same functionality also needs to be implemented in: BatchnormBackwardNode, BatchnormInferenceNode and BatchnormInferenceNodeVarianceExt. Without these changes, users cannot take full advantage of the relaxed affine tensor shape requirements for the batchnorm operation.

📅 Opened Jul 7, 2026💬 1 comment
Quality: 40/100Contribute

While investigating #8530, we reviewed other hipDNN frontend node property inference paths for cases where missing output tensor metadata may be ambiguous or inconsistent with cuDNN frontend behavior. SDPA backward is not ambiguous in the same way as convolution backward data/weight, but it still has validation and layout-policy gaps that should be tracked. Current behavior SdpaBwdNode::infer_properties_node() infers missing gradient output metadata as: dQ.dim = Q.dim dK.dim = K.dim dV.dim = V.dim missing dQ/dK/dV strides are generated with the default packed row-major/BHSD policy This shape inference is deterministic and mathematically correct for SDPA backward, including GQA/MQA: the gradients must match the original tensors they differentiate. This differs from cuDNN frontend, which generally expects backward output descriptors to be supplied, but it is not inherently unsafe the way convolution dx / dw inference can be unsafe. The gap is that hipDNN currently accepts caller-suppli

📅 Opened Jun 18, 2026💬 0 comments
Quality: 40/100Contribute

Context From PR #6296 review by @mousdahl-amd — merged as-is with this tracked as a follow-up. Problem The integration round-trip tests (JSON and binary serialize/deserialize) manually compare every field of the deserialized graph against expected values. This is verbose and fragile — each new field requires updating every round-trip test. Proposal Implement Equals, (Possibly call it LogicallyEquals) for: Graph Node (and its concrete subtypes or via virtual dispatch) Tensor operator == likely should also compare the backend descriptors, and for the checks we want here, it should be skipped. Likely want to split into two things with overlapping support. LogicallyEquals which compares logical equivalency of the graph state (Graph properties + Nodes + Tensor definitions all match). Operator==, that checks LogicallyEquals && the descriptor pointers / lowering state. Tests can use LogicallyEquals, and consumers can use LogicallyEquals for checking if graphs represent the same operatio

📅 Opened Apr 13, 2026💬 2 comments
Quality: 30/100Contribute
Looking for more Assembly beginner tasks?Explore Assembly GFI

Contributor Community Vibe Feedback

Rate what actually matters after opening a pull request here.

Have you contributed to this repo?

Rate your first-hand PR experience (review speed, maintainer responsiveness, and onboarding ease) to help other contributors.

3 ratings required
Maintainer helpfulness
Review speed
Beginner friendliness

Contributor Compatibility & Review Speed Analysis for ROCm/rocm-libraries

When evaluating whether to contribute to ROCm/rocm-libraries, response velocity and maintainer engagement are crucial. GetMerged continuously tracks pull request trajectories, first-comment latency, and code review rounds to help developers avoid submitting pull requests to backlogged repositories.

Currently, maintainers of ROCm/rocm-libraries acknowledge new external contributions in approximately <1 hour. Out of all submitted pull requests from non-core authors in the last 180-day window, 8.4% were successfully merged into the primary branch.

Frequently Asked Questions - Contributing to ROCm/rocm-libraries

01

Is ROCm/rocm-libraries welcoming to first-time open-source contributors?

ROCm/rocm-libraries has a recorded first-timer success rate of 15.5%. Repositories ranked Welcoming typically provide actionable feedback during code reviews and actively nurture new community contributors.

02

How fast can I expect code review feedback on my pull request?

The initial maintainer response time averages ~<1 hour. Keeping PRs scoped to single concerns and ensuring CI checks succeed will optimize review turnaround.

03

What does the 63.7 C-Rank™ score represent?

The C-Rank™ index scores repositories on a 0 to 100 scale using an objective formula: external PR merge rates, initial response speed, active maintainer count, and first-time contributor retention. A score of 63.7 places ROCm/rocm-libraries in the Welcoming tier.

04

What is the external contributor pull request merge rate for ROCm/rocm-libraries?

The external pull request merge rate is 8.4%. GetMerged isolates non-core community contributions so external developers get an accurate benchmark of PR acceptance probability.

05

Are there beginner Good First Issues open in ROCm/rocm-libraries?

Yes, ROCm/rocm-libraries currently has 7 active issue(s) tagged with beginner-friendly labels. You can inspect these directly from the repository issues tab.

GetMerged C-Rank™ Indexing Standard

All metrics displayed for ROCm/rocm-libraries are automatically retrieved via the public GitHub API and recalculated daily. Insider pull requests submitted by repository owners or organization members are excluded from merge rate calculations to preserve objective external contributor statistics.