Added few changes to repository_contributor file #1383
Conversation
Summary by CodeRabbit
Summary by CodeRabbit
WalkthroughThe changes introduce optional filter arguments ( Changes
Assessment against linked issues
Suggested labels
Tip ⚡️ Faster reviews with caching
Enjoy the performance boost—your workflow just got faster. 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (6)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
arkid15r
left a comment
arkid15r
left a comment
There was a problem hiding this comment.
We should take a look at these cases and refactor/consolide the code making sure that DRY principle is followed throughout the entire code base.
// Feel free to PM me if you have more questions.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
backend/apps/github/models/repository_contributor.py (1)
140-143: Simplify redundant condition in project filter.The project filter has a redundant condition that can be simplified.
- queryset = queryset.filter( - repository__project__key__iexact=f"www-project-{project}" if project else None - ) + queryset = queryset.filter( + repository__project__key__iexact=f"www-project-{project}" + )The outer
if project:check already ensures this code only runs when project is truthy, making the inner condition redundant.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
backend/apps/github/graphql/queries/repository_contributor.py(1 hunks)backend/apps/github/models/mixins/repository.py(1 hunks)backend/apps/github/models/repository_contributor.py(2 hunks)backend/apps/owasp/models/common.py(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- backend/apps/github/graphql/queries/repository_contributor.py
🧰 Additional context used
🧬 Code Graph Analysis (1)
backend/apps/owasp/models/common.py (1)
backend/apps/github/models/repository_contributor.py (2)
RepositoryContributor(14-191)get_top_contributors(109-191)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: Run frontend unit tests
- GitHub Check: Run backend tests
- GitHub Check: Run frontend e2e tests
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (8)
backend/apps/github/models/repository_contributor.py (6)
4-5: Good addition of necessary imports for query functionality.The new imports of
F,Sum, andWindowfromdjango.db.modelsalong withRankfromdjango.db.models.functionsare appropriate for the new functionality being added to the class.
108-123: Well-documented class method with clear purpose and parameters.This new class method provides a centralized implementation for retrieving top contributors, with good documentation that clearly explains the purpose, parameters, and return values.
124-139: Good base query construction with appropriate filters.The initial queryset construction and repository/organization filtering looks well-implemented, using appropriate select_related calls to optimize database access.
145-160: Effective implementation of top contributors ranking logic.The ranking implementation using Window functions is an efficient approach to get the top contributor per user when not filtering by repositories. Using the Rank window function with partitioning by user login ensures we get each user's best contribution.
161-174: Efficient aggregation and conditional annotations.Good use of values() and annotate() to efficiently aggregate total contributions and conditionally add project information only when needed.
175-191: Clean result formatting with proper data transformation.The method appropriately transforms the raw query result into a standardized format, including stripping the "www-project-" prefix from project keys when present.
backend/apps/github/models/mixins/repository.py (1)
102-104: Good refactoring to use centralized method.The property has been simplified to use the new centralized
get_top_contributorsmethod, reducing code duplication and improving maintainability.backend/apps/owasp/models/common.py (1)
196-198: Clean implementation using centralized method.The method has been refactored to delegate to the new
RepositoryContributor.get_top_contributorsmethod, simplifying the code while maintaining the same functionality.
arkid15r
left a comment
arkid15r
left a comment
There was a problem hiding this comment.
We want to migrate all separate cases to a single endpoint supporting filtering for any entity -- entire organization, project, chapter, commitee, repository, etc.
Here are graphql queries to migrate - https://github.com/search?q=repo%3AOWASP%2FNest%20topContributors%20path%3A**%2Fqueries%2F**&type=code
|
@samyak003 are you still interested in finishing this task? |
|
Yes, I'll complete this task by this weekend |
|
@samyak003 I didn't see any promised updates 🤷♂️ |
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
backend/apps/github/models/repository_contributor.py (1)
194-211: 💡 Verification agent🧩 Analysis chain
Clean result formatting with prefix handling.
The result transformation cleanly formats the output dictionaries and handles the removal of the "www-project-" prefix from project keys. The use of
get()with default values ensures the method handles cases where project information might not be present.Consider adding a unit test to verify that this method behaves correctly with various combinations of filter parameters, particularly checking the project_key formatting.
🏁 Script executed:
#!/bin/bash # Check if there are tests for the get_top_contributors method echo "Searching for test files for RepositoryContributor model..." fd "test.*repository_contributor.*\.py" --type f echo "\nSearching for tests of the get_top_contributors method..." rg "test.*get_top_contributors" --type pyLength of output: 352
Add missing unit tests for get_top_contributors
It looks like there aren’t any existing tests covering the
get_top_contributorsmethod inbackend/apps/github/models/repository_contributor.py. Please add unit tests to ensure:
- The method returns the correct number of contributors and respects the
limit.- Contributions are ordered descending by
total_contributions.project_keyformatting:
- Returns
Nonewhenproject_keyis absent.- Strips the
"www-project-"prefix when present.project_name,login,name,avatar_url, andcontributions_countare all populated (orNonewhere expected).
🧹 Nitpick comments (4)
frontend/src/app/chapters/[chapterKey]/page.tsx (1)
27-27: Consider adding a null check for topContributors data.While the implementation correctly sets the topContributors state, there's no explicit check for
data?.topContributorsbeing undefined.- setTopContributors(data?.topContributors) + setTopContributors(data?.topContributors || [])frontend/src/app/organizations/[organizationKey]/repositories/[repositoryKey]/page.tsx (1)
32-32: Consider adding a null check for topContributors data.While the implementation correctly sets the topContributors state, there's no explicit check for
data?.topContributorsbeing undefined.- setTopContributors(data?.topContributors) + setTopContributors(data?.topContributors || [])frontend/src/app/committees/[committeeKey]/page.tsx (1)
36-36: Consider adding a null check for topContributors data.While the implementation correctly sets the topContributors state, there's no explicit check for
data?.topContributorsbeing undefined.- setTopContributors(data?.topContributors) + setTopContributors(data?.topContributors || [])frontend/src/app/projects/[projectKey]/page.tsx (1)
34-34: Consider adding a null check for topContributors data.While the implementation correctly sets the topContributors state, there's no explicit check for
data?.topContributorsbeing undefined.- setTopContributors(data?.topContributors) + setTopContributors(data?.topContributors || [])
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
backend/apps/github/graphql/queries/repository_contributor.py(1 hunks)backend/apps/github/models/repository_contributor.py(2 hunks)frontend/src/app/chapters/[chapterKey]/page.tsx(4 hunks)frontend/src/app/committees/[committeeKey]/page.tsx(3 hunks)frontend/src/app/organizations/[organizationKey]/repositories/[repositoryKey]/page.tsx(3 hunks)frontend/src/app/projects/[projectKey]/page.tsx(4 hunks)frontend/src/server/queries/chapterQueries.ts(1 hunks)frontend/src/server/queries/committeeQueries.ts(1 hunks)frontend/src/server/queries/projectQueries.ts(1 hunks)frontend/src/server/queries/repositoryQueries.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (5)
frontend/src/app/organizations/[organizationKey]/repositories/[repositoryKey]/page.tsx (2)
frontend/src/types/contributor.ts (1)
TopContributorsTypeGraphql(8-15)frontend/src/server/queries/repositoryQueries.ts (1)
GET_REPOSITORY_DATA(3-56)
frontend/src/app/committees/[committeeKey]/page.tsx (2)
frontend/src/types/committee.ts (1)
CommitteeDetailsTypeGraphQL(21-35)frontend/src/types/contributor.ts (1)
TopContributorsTypeGraphql(8-15)
frontend/src/app/chapters/[chapterKey]/page.tsx (1)
frontend/src/types/contributor.ts (1)
TopContributorsTypeGraphql(8-15)
frontend/src/app/projects/[projectKey]/page.tsx (1)
frontend/src/types/contributor.ts (1)
TopContributorsTypeGraphql(8-15)
backend/apps/github/models/repository_contributor.py (3)
backend/apps/owasp/models/common.py (1)
get_top_contributors(196-198)backend/apps/github/models/repository.py (1)
project(150-152)backend/apps/github/models/managers/repository_contributor.py (4)
by_humans(12-16)by_humans(36-38)to_community_repositories(18-20)to_community_repositories(40-42)
🔇 Additional comments (26)
frontend/src/server/queries/projectQueries.ts (1)
62-67: Good refactoring of top contributors to root level queryMoving
topContributorsfrom being nested inside theprojectobject to a separate top-level field with a project filter parameter is a solid architectural improvement. This change:
- Decouples contributor data from project data
- Enables more flexible data fetching
- Follows the pattern of centralizing contributor logic on the backend
The implementation correctly passes the project key as a parameter and maintains the same field selection.
frontend/src/server/queries/chapterQueries.ts (1)
20-25: Good consistent refactoring of top contributorsThis change correctly follows the same pattern used in projectQueries.ts, moving
topContributorsto a root-level field with a chapter filter parameter. The consistent approach across different entity types improves maintainability and indicates a thoughtful architectural decision.frontend/src/server/queries/repositoryQueries.ts (1)
49-54: Appropriate refactoring with dual parameter filteringMoving
topContributorsto a root-level field with both repository and organization filters correctly implements the refactoring pattern. This maintains consistency with the other query files while appropriately handling the repository context which requires both repository and organization identifiers.frontend/src/server/queries/committeeQueries.ts (1)
19-26: Enhanced contributor data with project informationThis change follows the established refactoring pattern but extends the contributor fields to include
projectKeyandprojectName. This enhancement provides valuable context when displaying committee contributors, associating them with their respective projects.frontend/src/app/chapters/[chapterKey]/page.tsx (3)
8-8: Appropriate import for the refactored approach.The import of
TopContributorsTypeGraphqlis correctly added to support the new state management approach for top contributors.
17-17: Good separation of concerns with new state variable.Creating a dedicated state variable for top contributors properly decouples this data from the chapter object, aligning with the backend changes that now support filtering contributors by chapter.
70-70: Correctly updates prop to use the new state variable.The component now correctly passes the dedicated
topContributorsstate to theDetailsCardinstead of accessing it through the chapter object.frontend/src/app/organizations/[organizationKey]/repositories/[repositoryKey]/page.tsx (3)
15-15: Appropriate import for the refactored approach.The import of
TopContributorsTypeGraphqlis correctly added to support the new state management approach for top contributors.
24-24: Good separation of concerns with new state variable.Creating a dedicated state variable for top contributors properly decouples this data from the repository object, aligning with the backend changes that now support filtering by repository and organization.
115-115: Correctly updates prop to use the new state variable.The component now correctly passes the dedicated
topContributorsstate to theDetailsCardinstead of accessing it through the repository object.frontend/src/app/committees/[committeeKey]/page.tsx (3)
15-15: Appropriate import for the refactored approach.The import of
TopContributorsTypeGraphqlis correctly added to support the new state management approach for top contributors.
23-23: Good separation of concerns with new state variable.Creating a dedicated state variable for top contributors properly decouples this data from the committee object, aligning with the backend changes that now support filtering by committee.
91-91: Correctly updates prop to use the new state variable.The component now correctly passes the dedicated
topContributorsstate to theDetailsCardinstead of accessing it through the committee object.frontend/src/app/projects/[projectKey]/page.tsx (3)
14-14: Appropriate import for the refactored approach.The import of
TopContributorsTypeGraphqlis correctly added to support the new state management approach for top contributors.
25-25: Good separation of concerns with new state variable.Creating a dedicated state variable for top contributors properly decouples this data from the project object, aligning with the backend changes that now support filtering by project.
103-103: Correctly updates prop to use the new state variable.The component now correctly passes the dedicated
topContributorsstate to theDetailsCardinstead of accessing it through the project object.backend/apps/github/graphql/queries/repository_contributor.py (4)
17-20: Excellent extension of the filtering capabilities!You've added new optional filter parameters (project, chapter, committee, repository) to the top_contributors GraphQL query. This allows for more flexible and precise querying of contributor data, which will enhance the usability of this API endpoint.
23-43: Good docstring updates and parameter handling.The resolver method signature has been properly updated to include all the new filter parameters, and the docstring has been expanded with clear descriptions of each parameter. This makes the API well-documented and ensures future developers understand how to use these parameters.
49-56: Clean implementation using the centralized method.The refactoring to use
RepositoryContributor.get_top_contributors()centralizes the query logic and makes this resolver much cleaner. This approach will be more maintainable as it eliminates duplicate query logic across the codebase.
59-65: Simplified field mapping in the result transformation.The mapping of query results to
RepositoryContributorNodefields has been simplified by directly accessing the flattened dictionary keys returned by the newget_top_contributorsmethod. This is more readable and less error-prone than handling nested dictionary keys.backend/apps/github/models/repository_contributor.py (6)
4-5: Appropriate imports for advanced ORM functionality.Adding imports for
F,Sum,Windowfromdjango.db.modelsandRankfromdjango.db.models.functionsallows for efficient in-database aggregation and ranking operations, which are essential for theget_top_contributorsmethod.
108-133: Well-documented method signature.The class method
get_top_contributorshas a comprehensive docstring that clearly explains the purpose and all parameters. This is excellent practice for maintainability and will help other developers understand how to use this method.
134-138: Efficient base queryset construction.Starting with a clean queryset that filters to human contributors, community repositories, and uses
select_relatedfor related models is an excellent approach for performance optimization.
143-162: Consistent filtering patterns for different entity types.The filtering logic consistently uses
iexactfor case-insensitive matching and properly handles the prefix conventions (e.g., "www-project-") for project, chapter, and committee keys. This ensures the API is user-friendly while maintaining compatibility with the database's naming conventions.
164-179: Sophisticated ranking logic for non-repository-specific queries.Using window functions to rank contributors by contribution count and filtering to the top contributor per user is an efficient approach. This ensures that users don't appear multiple times in the results when querying across repositories, which provides a cleaner user experience.
181-193: Smart conditional project information inclusion.Only including project information when not already filtering by project, organization, or repositories avoids redundancy and ensures the response contains relevant information based on the query context.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
backend/apps/github/models/repository_contributor.py (1)
159-171: Consider adding a comment explaining the rank filtering logic.The Window function with Rank is a powerful feature, but its purpose might not be immediately clear to all developers. Consider adding a comment explaining that this is used to select only the top contribution from each user across multiple repositories.
# Project contributors only for main/project/organization pages. if not (chapter or committee or repository): queryset = ( queryset.filter(repository__project__isnull=False) .annotate( rank=Window( expression=Rank(), order_by=F("contributions_count").desc(), partition_by=F("user__login"), ) ) + # Only include the user's top contribution repository to avoid counting the same user multiple times .filter(rank=1) )
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
backend/apps/github/graphql/queries/repository_contributor.py(1 hunks)backend/apps/github/models/mixins/repository.py(1 hunks)backend/apps/github/models/repository_contributor.py(2 hunks)backend/apps/owasp/models/common.py(0 hunks)backend/apps/owasp/models/mixins/chapter.py(2 hunks)backend/apps/owasp/models/mixins/committee.py(2 hunks)backend/apps/owasp/models/mixins/project.py(2 hunks)frontend/__tests__/e2e/pages/ChapterDetails.spec.ts(1 hunks)frontend/__tests__/unit/data/mockChapterDetailsData.ts(1 hunks)frontend/__tests__/unit/data/mockCommitteeDetailsData.ts(1 hunks)frontend/__tests__/unit/data/mockProjectDetailsData.ts(1 hunks)frontend/__tests__/unit/data/mockRepositoryData.ts(1 hunks)frontend/__tests__/unit/pages/ChapterDetails.test.tsx(3 hunks)frontend/__tests__/unit/pages/CommitteeDetails.test.tsx(2 hunks)frontend/src/app/committees/[committeeKey]/page.tsx(2 hunks)
💤 Files with no reviewable changes (1)
- backend/apps/owasp/models/common.py
🚧 Files skipped from review as they are similar to previous changes (2)
- frontend/src/app/committees/[committeeKey]/page.tsx
- backend/apps/github/models/mixins/repository.py
🧰 Additional context used
🧬 Code Graph Analysis (6)
frontend/__tests__/e2e/pages/ChapterDetails.spec.ts (1)
frontend/__tests__/unit/data/mockChapterDetailsData.ts (1)
mockChapterDetailsData(1-36)
frontend/__tests__/unit/pages/ChapterDetails.test.tsx (1)
frontend/__tests__/unit/data/mockChapterDetailsData.ts (1)
mockChapterDetailsData(1-36)
backend/apps/owasp/models/mixins/committee.py (1)
backend/apps/github/models/repository_contributor.py (2)
RepositoryContributor(12-200)get_top_contributors(113-200)
backend/apps/owasp/models/mixins/chapter.py (1)
backend/apps/github/models/repository_contributor.py (2)
RepositoryContributor(12-200)get_top_contributors(113-200)
frontend/__tests__/unit/pages/CommitteeDetails.test.tsx (1)
frontend/__tests__/unit/data/mockCommitteeDetailsData.ts (1)
mockCommitteeDetailsData(1-24)
backend/apps/owasp/models/mixins/project.py (2)
backend/apps/github/models/repository_contributor.py (2)
RepositoryContributor(12-200)get_top_contributors(113-200)backend/apps/github/models/repository.py (1)
project(152-154)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: Run frontend unit tests
- GitHub Check: Run backend tests
- GitHub Check: CodeQL (python)
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (27)
frontend/__tests__/unit/data/mockCommitteeDetailsData.ts (1)
10-23: LGTM! Data structure refactor correctly decouples contributors from committee entity.The change correctly implements the refactored data structure where
topContributorsis now a top-level property rather than nested inside thecommitteeobject. This aligns with the broader architectural changes to query top contributors as a separate entity across the application.frontend/__tests__/e2e/pages/ChapterDetails.spec.ts (1)
9-9: LGTM! Mock JSON structure correctly updated to match refactored GraphQL response.The mock response structure has been updated to directly use
mockChapterDetailsDataas the data property, which aligns with the changes in the GraphQL query structure wheretopContributorsis now queried as a separate root-level field.frontend/__tests__/unit/pages/ChapterDetails.test.tsx (3)
36-36: LGTM! Updated mock data structure for useQuery hook.The test mock correctly reflects the refactored GraphQL query response structure where the data is no longer nested inside a
chapterproperty.
59-59: LGTM! Consistent mock data structure for useQuery hook.The change maintains consistency with the updated data structure pattern across all test cases.
112-112: LGTM! Consistent mock data structure for incomplete contributors test case.The test case for handling incomplete contributor data correctly follows the same pattern of directly using the data object without extra nesting.
frontend/__tests__/unit/data/mockProjectDetailsData.ts (1)
94-99: LGTM! Top contributors moved to top-level property.The
topContributorsarray has been correctly moved from being nested inside theprojectobject to being a top-level property in the exportedmockProjectDetailsDataobject. This aligns with the broader refactoring pattern applied consistently across the codebase.frontend/__tests__/unit/data/mockRepositoryData.ts (1)
63-68: LGTM: Mock data structure updated to reflect architectural changesThe refactoring of the
topContributorsarray from a nested property inside the repository object to a top-level property matches the structural changes made to the GraphQL queries. This properly aligns the mock data with how top contributors are now managed as separate state in the React components.backend/apps/owasp/models/mixins/committee.py (2)
5-5: Import of RepositoryContributor added correctlyThis import enables the use of the centralized
get_top_contributorsclass method.
30-30: Good refactoring: Centralized top contributors retrievalThe property now uses the centralized
RepositoryContributor.get_top_contributorsclass method with the committee key as a filter parameter, which aligns with the architectural change to standardize contributor retrieval across the application.frontend/__tests__/unit/pages/CommitteeDetails.test.tsx (3)
29-29: Test mock updated to use new data structureThe mock data structure now correctly reflects the updated GraphQL query response shape where data is provided directly rather than nested under a committee property.
84-94: Test fixture correctly restructuredThe
committeeDataWithIncompleteContributorsobject has been properly restructured to havecommitteeandtopContributorsas sibling properties at the top level, which matches the new GraphQL response format.
96-96: Test mock updated to match new data structureThe useQuery mock now returns the entire data object directly, matching how the actual component would receive GraphQL data after the refactoring.
backend/apps/owasp/models/mixins/chapter.py (3)
3-4: Future annotations import addedThe
__future__.annotationsimport allows for using forward references in type annotations, which is good practice in Python files with circular dependencies.
5-5: Import of RepositoryContributor added correctlyThis import enables the use of the centralized
get_top_contributorsclass method.
74-74: Good refactoring: Centralized top contributors retrievalSimilar to the committee mixin, this property now uses the centralized
RepositoryContributor.get_top_contributorsclass method with the chapter key as a filter parameter, streamlining how contributors are fetched across different entity types.backend/apps/owasp/models/mixins/project.py (2)
6-6: New import looks good.The import of
RepositoryContributorfromapps.github.models.repository_contributoris correctly added to support the updated implementation.
105-108: Implementation refactored to use centralized method.The
idx_top_contributorsproperty now uses the centralizedRepositoryContributor.get_top_contributorsclass method instead of a local implementation. This is a good refactoring that promotes code reuse and consistency.frontend/__tests__/unit/data/mockChapterDetailsData.ts (1)
1-29: Test data structure aligned with updated GraphQL schema.The mock data structure has been updated to nest chapter-specific properties under a
chapterobject, reflecting changes in the GraphQL schema. This structure change properly mimics how the data will be returned from the API.backend/apps/github/graphql/queries/repository_contributor.py (3)
15-23: Good enhancement of filter options for the top_contributors query.Adding optional filter parameters for
chapter,committee,project, andrepositoryimproves the flexibility of the API and allows clients to retrieve more specific data.
25-51: Well-documented resolver with clear parameter descriptions.The resolver method signature and docstring have been properly updated to reflect the new parameters, providing clear documentation for future developers.
52-71: Simplified resolver implementation using centralized model method.The resolver now delegates to the centralized
RepositoryContributor.get_top_contributorsmethod instead of containing complex query logic. This is a good refactoring that separates concerns and makes the code more maintainable.backend/apps/github/models/repository_contributor.py (6)
4-5: Added necessary imports for the new method.The imports for
F,Sum, andWindowfromdjango.db.modelsandRankfromdjango.db.models.functionsare correctly added to support the newget_top_contributorsmethod.
112-135: Well-structured method signature and documentation.The new
get_top_contributorsclass method has a clear signature with appropriate default values and comprehensive docstring documentation for all parameters.
136-171: Robust filtering logic with appropriate context-based handling.The implementation properly builds the queryset with appropriate filters based on the provided parameters. The special handling for project contributors when no chapter, committee, or repository filter is applied is a thoughtful design choice.
172-186: Efficient aggregation and ordering of contributors.The query effectively aggregates contributions by user and includes relevant project information, with proper ordering and limit application.
188-200: Clean data transformation for API consumption.The method returns a well-structured list of dictionaries with all necessary contributor information, correctly handling the project key transformation.
112-200: Comprehensive centralized implementation that improves code organization.The new
get_top_contributorsmethod successfully centralizes the logic for retrieving top contributors, which was previously scattered across multiple places. This refactoring improves maintainability, reduces code duplication, and provides a consistent interface for different parts of the application.
|
* Added few changes to repository_contributor file * Refactored the code * Added few changes * Update code * Refactor code * Fix tests * Update code --------- Co-authored-by: Arkadii Yakovets <[email protected]>
2 participants
Fixes: #1353