Redmine

Hello,
Here's what can be gathered about Redmine's issue processing workflow and the specific issues you've mentioned:

Redmine's General Issue Processing Workflow:

Redmine, as a project management and issue tracking tool, is highly configurable. The exact workflow can vary significantly depending on how a specific Redmine instance is set up by its administrators. However, some common elements and general principles apply:

Issue Creation: Users submit issues, typically selecting a "tracker" (e.g., Bug, Feature, Support) and providing a subject and description.

Categories and Assignees: Ideally, issues are categorized and assigned to a responsible person or team. This helps in organizing and directing the issue. You noted that newer issues have categories, which is a good sign that they are being triaged.

Statuses and Transitions: Issues move through different statuses (e.g., New, In Progress, Resolved, Closed). Workflows define which status transitions are allowed for different roles and trackers.

Priorities: Issues are often assigned priorities (e.g., Low, Normal, High, Urgent, Immediate) to indicate their importance.

Target Versions/Roadmaps: Issues can be associated with target versions or roadmaps, indicating when they are intended to be addressed.

Community Contribution (for open-source projects like Redmine itself): For projects like Redmine, patches and proposed solutions from the community are common. These need to be reviewed by core developers.

Regarding your specific issues:

Issue #14418: "Copy inner issues relations along with issues" (Feature)

This issue was created a long time ago (over 11 years) and is a "Feature" request.

Its current status is "New" and the "Target version" is "Candidate for next major release."

The description clearly states the problem: when copying issues, their relations (like "precedes/follows" or "blocks/blocked by") are lost, which is particularly frustrating for structured tasks.

It's a highly requested feature, as indicated by the various comments and its long-standing presence. The fact that it's marked as a "Candidate for next major release" suggests it's on the radar for significant future development, but not necessarily for a quick implementation.

Issue #42081: "Copying following tasks" (Patch)

This is a "Patch" issue, which means you've provided a code solution. This is a very valuable contribution!

It's explicitly stated as a duplicate of #14418, meaning it aims to resolve or contribute to the solution of that long-standing feature request.

The "Category" and "Assignee" fields are currently empty, and the "Target version" is also blank. This is likely what you're observing as "not processed."

Why your patch (42081) might not have been categorized/assigned yet, despite newer issues being processed:

Nature of a Patch vs. New Issues: Newly reported bugs or minor feature requests might be easier to quickly categorize and assign to a developer for immediate review. A patch, especially for a complex feature like relation copying, requires a more thorough review process.

Core Developer Bandwidth: The Redmine project is open-source, and development relies on a core team and community contributions. There might be limited resources or time for reviewing and integrating complex patches.

Thorough Review Required: A patch for a core functionality like issue relations needs careful review to ensure it:

Doesn't introduce regressions or new bugs.

Aligns with the project's overall architecture and coding standards.

Is robust and handles various edge cases.

Is compatible with future Redmine versions https://www.mykfcexperience.me

Integration with a Larger Feature (14418): Since your patch directly addresses #14418, it might be waiting for the core team to prioritize and plan the full implementation of #14418. Even with a patch, integrating it might involve further discussion, refinement, or a broader overhaul of related code.

"Candidate for next major release" status of #14418: This status, while indicating future intent, often means it's not a priority for minor releases or immediate integration. Major releases often involve larger architectural changes and a longer development cycle.

Communication and Follow-up: While you've submitted the patch, sometimes a gentle follow-up on the issue itself, or perhaps a post on a Redmine forum (if available) might help to bring it back to the attention of the core developers.

What you can do:

Monitor the Issue: Keep an eye on #42081 and #14418 for any updates or comments from the Redmine developers.

Add More Information (if applicable): If there's any additional context, testing notes, or further improvements you can make to your patch, adding comments to the issue might be helpful.

Patience: Unfortunately, with open-source projects, the pace of development can sometimes be slower due to volunteer efforts. Complex features and patches often take time to be reviewed and integrated.

Thank you very much for your response, I was losing hope :)