Ticket #1450 (closed RFC: worksforme)
Improve handling of experimental features
|Reported by:||whiteknight||Owned by:|
I would like to suggest some changes with regards to features labeled "experimental":
- Create an EXPERIMENTAL.pod file to keep experimental items (on their way in) separated from deprecated items (on their way out)
- That features labeled experimental have a certain time-limit. Beyond that time, say two stable releases, we have to make a decision whether the feature is suitable for permanent addition to the API, whether it needs to be improved, or whether it can be safely deleted.
- That we update the #parrotsketch meeting process to regularly evaluate these items for viability
- That we add a ticket Type "experimental" on Trac, and associate all experimental features with a ticket. Many experimental features have associated tickets now as problems that the experimental feature tries to fix. However, these aren't tickets that assure we properly triage these features in a timely manner. Also, not all experimental features are added as a response to a bug.
Input on this issue would be very helpful.