OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: template for feature proposals


To make it easier to categorize and prioritize features, each feature should be supported by a feature proposal template.

Perhaps we could agree on some field names for the criteria and other information about the feature. Then any fields that are relevant can be added to the template in the prescribed positions.

Here's a candidate that we can improve on.

Best wishes,

Bruce Esrig

Information Developer / Information Architect, Information Products and Training (IP&T)
Lucent Technologies, 67 Whippany Road Room 14C-348, Whippany, NJ, 07981
+1 973 739 1235, esrig@lucent.com

=============================

Feature title: A few distinctive keywords to identify the feature
Level affected: Choose a level among Architecture, Type declarations, Instances. If the feature will affect more than one level, note the other affected levels.
Aspect affected: Within the level, state additional information on how to classify the feature.

User goal: Define the problem that the feature would address
User scenario: Present a plausible scenario in which the feature would be used, treating the feature as a black box that operates in an unknown manner.
Background: Describe other contexts, including contexts outside of DITA, in which the feature may occur. Include references, if available.

Benefits: State the value of having the feature, with any attendant costs of having the feature. Does it support tasks that are critical, difficult, and/or frequent? Does it create conceptual complexity for its users? Does it conflict with or replace other existing or proposed features? If applicable, identify the feature as a best practice. (A best practice establishes a norm in an arena previously offering a variety of choices, where some of the choices may not be good in the long term and some choices may offer needless variety). (Shall we create a separate document in which to report best practices? Some best practices may already reside in the architectural specification.)
Drivers: State any external forces that make it important to consider implementing this feature. Name any persons or organizations who are actively advocating having the feature implemented.
Team: State a primary contact within the DITA TC for the feature. Name any persons or organizations with special interests in contributing to the feature definition or implementation.
Risks: State the risks and opportunity costs of trying to introduce the feature.
Difficulty: Summarize the difficulty of providing the feature.

Feature operation: Present information on how the feature would work. 
Implementation impacts on architecture: State any architectural changes (at a semantic level) that would be required.
Implementation impacts on type declarations: State what type declarations would be introduced or modified.
Implementation impacts on instances: State what markup would be used.
Implementation impacts on processing: State what additional support would be required from processing tools.
Impacts on documentation: State how the specification or language reference would change.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]