features.md

features.md

Managing Feature Requests for Joomla on GitHub

Objective

To create a structured, transparent, and efficient process for handling Joomla feature requests, from initial idea through evaluation, approval, and implementation, using GitHub Discussions and Issues.

1. Feature Areas Overview

• New Feature Ideas: Open space for all contributors to post ideas
• Cold Feature Ideas: Existing feature ideas that are either oldert than X or have had little interest
• Feature Evaluation: Community discussion area; ideas under active review
• Approved Features: Ideas that will be implemented, with target Joomla version indicated
• Implemented Features: Completed and shipped features including Joomla version
• Rejected Features: Ideas that will not be implemented, with reasoning for transparency
• Duplicated Features: Ideas that already exist with link

---

2. Existing Feature Requests

To organize the current backlog of feature requests:

• All existing issues flagged as Feature will be moved to the new Feature Request Discussion area.
• Classification based on activity:
  • NEW Features – Issues with the last comment in 2025/2026.
  • COLD Features – Issues with the last comment before 2025.

This ensures maintainers and contributors can focus on active ideas while keeping historical requests accessible.

---

3. Workflow for New Feature Requests

Step 1: Create a New Feature Idea

• Anyone can post a new feature idea in the New Feature Ideas discussion area.
• Each idea should include:
  • Problem statement
  • Proposed solution
  • Expected benefit or use case
  • Optional: screenshots, mockups, or links to examples

---

Step 2: Feature Evaluation

• Once a new feature is posted, maintainers will either:
  • Reject the idea (with explanation), or
  • Move it to Feature Evaluation for further community discussion
• Timeline Suggestion: Move within 2–4 weeks of posting
• During Feature Evaluation:
  • Anyone can comment, provide feedback, or discuss potential improvements
  • Maintain a constructive, collaborative tone

---

Step 3: Approval or Rejection

• After evaluation, maintainers will either:
  • Reject the feature (with rationale), or
  • Approve the feature and move it to Approved Features
• Timeline Suggestion: Decision should occur within 4–6 weeks of entering evaluation
• When approving, maintainers can set a Minimum target Joomla version for implementation (there may be backwards compatibility restrictions)

---

Step 4: Implementation

• Approved features are implemented in the Joomla codebase.
• Once implemented, the feature is moved to Implemented Features, marking it as completed and the Joomla version it has been merged to.

---

4. Roles and Permissions

Role	Permissions / Responsibilities
Anyone	Post New Feature Ideas, comment on Feature Evaluation discussions
Maintainers	Move ideas through stages (Evaluation → Approved/Rejected), set target Joomla version, provide guidance and timelines, close discussions after decision

5. Additional Guidelines

• Encourage community participation but maintain clear timelines
• Maintainers should provide clear rationale when rejecting ideas Have a set of pre-written explanations that can be used.
• Use labels to indicate status (e.g., new, evaluation, approved, implemented, rejected)
• COLD Features can be reviewed at any time

---

This workflow creates transparency, encourages community engagement, and ensures Joomla development is responsive to genuine user needs while maintaining maintainers’ oversight.

---

When approving, maintainers must set a target Joomla version for implementation

doesn't work like that, because we don't provide the "implementor", so we can only say "yes or no", if nobody picks up the feature and implement it, it will be in the "approved list" for ever.

COLD Features, are more or less the legacy archive, it's hard to look at all the requests. So I wouldn't like to make promises which will never happen.

It's possible that github doesn't allow us to make a clear cut between archive and active discussions. For example if we have duplicates we would need to close/archive/delete? them without moving it to rejected feature... So maybe we have a 6. category. with archive/duplicates.

May plan is not to use labels instead to use the categories to set the "status". And I think it better to remove the "voting category" it's a special category in github which you can't move discussion in or out. We have thumb up and down in the discussion to get the "silent" feedback.

We plan to have the 1st category (New features idea) tidy, only active features requests should be in this category, in a short cycle they should be moved to approved or rejected or if it's not the time for it move it to cold features (but that should be an exception).

for the time being that's not the "official voted way by production" it's the way we want to fix the issue tracker structure.

If this works out, I think we go to production and replace the existing RFC process with this process.

Changed
COLD Features can be reviewed at any time

Changed

• When approving, maintainers can set a Minimum target Joomla version for implementation (there may be backwards compatibility restrictions)

Added
Duplicated Features: Ideas that already exist with link