Wiki Recommendations

BKCASE Workshop VNicole HutchisonSandy Friedenthal

Hans-Peter de KoningPaola di Maio

Stephanie Enck

I think that to use the wiki mechanism as a tool for collecting comments is a good idea. If it were published in a wiki form it would be possible to have a general call for contributions or comment which would be active all the time . . . Using the wiki as a mechanism for collecting comments continuously requires the use of the wiki technology but does not, of itself, demand and excessive contribution by whoever is maintaining the documents.

Community Support for a Wiki Version of SEBoK™

SEBoK 0.5 review included the question: Do you think the SE community would benefit from and embrace a Wiki-like (interactive online) structure as the portal for SEBoK v1.0? Please share your thoughts, concerns, experience, etc.

– 89 of the 114 reviewers responded to this question– Generally, reviewers viewed positively (but most of these had

concerns about implementation and stability)

Absolutely yes . . . The levels of complexity, and therefore the potential for unwanted emergence and the need for systems thinking, grows at an unprecedented rate, and therefore it will be hoped that the understanding and knowledge will grow (hopefully faster!). Therefore the knowledge must be alive!

Yes, I believe the SE community would embrace a Wiki embodiment of the SEBOK. This would be ideal because the accessibility of the SEBOK over the Internet would greatly facilitate the dissemination, use, and evolution of the SEBOK. Some form of editorial governance will be needed to ensure updates to the SEBOK contents are credible and authoritative.

Anything less is a waste of time except for professors and SE's' over 50 years of age. If it ain't color video it ain't mindshare.

Yes, I believe SEBoK will benefit from a Wiki-based structure, but also believe there always has to be an option to print the entire SEBoK because everyone processes and uses data differently and a significant portion of the users will want to be able to print the entire book and use the hardcopy, mark it up, etc.

Factors to Consider• Internal Consistency: The SEBoK, as a formal body of knowledge that is the result of inputs

from a broad community of authors, and needs to be internally consistent; i.e., it should not contain contradictions, unless those contradictions are properly explained as stemming from disagreements in the community on a certain subject.

• Stability: Because a body of knowledge is intended to provide a reference for the field, it must have some level of stability. If, for example, it were to change rapidly, it would be difficult to trace the different versions of the BoK in use and it would be possible that individuals accessing different versions of the BoK could be receiving widely different sets of information.

• Semantic Linkages: The purpose of the SEBoK is to provide guidance on how to navigate systems engineering literature in order to gain access to information. The ability to search the SEBoK and relate information to other topics, definitions, and additional resources is critical; semantic linkages enable this.

• Evolution: It is necessary that a BoK be updated to reflect advances in a field. New techniques, methodologies, approaches, models, and research must be incorporated into a BoK to enable it to remain current. In a field such as SE, which is rapidly growing and evolving, the ability of a BoK to evolve to keep pace is important.

• Access: It is a tenet of the BKCASE project—that all deliverables must be freely accessible to the public.

• Cost: Any costs related to the implementation above and beyond the costs associated with content development (these costs are considered constant regardless of delivery).

Options under Consideration

Four possible options for delivering a linked and cross-referenced version of the SEBoK are:• Hyperlinked PDF• Static Wiki with Periodic Updates• Evolving Wiki• Open Wiki

Recommendations• Development (to version 1.0):

– Initial structure: Static Wiki based on 0.5 documents (need to determine when appropriate)

– Editing: Evolving Wiki for content update (Authors provide materials to Part Leads, who make updates)

– Final/Technical Editing and 0.5 Review: Static Wiki (Core Team and Tech Editors make updates)

• Sustainment (post version 1.0):– Static wiki with discussion threads open to public

– Updates made periodically, as with a traditional document, but with specific insights gathered over time through comments

– Costs over traditional document maintenance are minimal and include server costs and labor to monitor comment threads (ensure appropriate, non-offensive, etc.)

Topic 2 (Article Title)Lorem ipsum dolor sit amet[1], consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor[2] in hendrerit in vulputate velit esse molestie consequat, vel illum dolor eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.

Lorem ipsum[3] dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore

Body – Generated from 0.5 Materials

magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. [4]

Part 1Part 2Part 1

KA 1KA 2Topic 1Topic 2

KA 3Part 4Part 5

Discussion ThreadPlease provide any comments on Topic 2 below.

Comment Entry Area (access controls TBD)

Comment 1: User XXXXXBody of Comment

Comment 2: User XXXXBody of Comment . . . .

Community Involvement & Conversation: Specific aspect of wiki development

Related TopicsTopic 1Topic 2Topic 3Topic 4. . . .

CitationsCitation 1Citation 2Citation 3Citation 4. . . .

Related Primary References

Reference 1Reference 2. . . .

GlossaryTerm 1Term 2Term 3Term 4. . . .

Figure Caption

Guidance Materials

Citations, Glossary, and primary references – Generated from 0.5 materials

Related Primary References and Related topics: New efforts unique to Wiki discussion

Systems Engineering Body of Knowledge (SEBoK)

SEBoK Map: Generated from TOC

Way Ahead

• Workshop V—Determine approach for version 0.5• Wiki team:

– Review cost data to verify selection is appropriate– Determine appropriate technology/server options– Draft framework for 0.5 (based on author team work)– Work with Core Team to develop a technical review/editing plan for version 0.5

• Milestones (subject to change):– Workshop VI: Draft Architecture– May: Initial 0.5 materials imported to Wiki environment (Static)– June: Authors begin working in Wiki environment (Evolving)– Workshop VII: Any issues with Wiki use are discussed addressed– August: Final drafts of materials in Wiki (Static—by author team)

Draft of additional SEBoK Views (author team and wiki team)– August-Sept: Technical editing; Core Team coordination with Part Leads to close

gaps, correct redundancies, etc.– Sept: 0.5 Open for review (Static with comment feature enabled)

Backups

Hyperlinked PDFThe hyperlinked PDF concept is based on the idea that the SEBoK could be developed as a traditional document and that linkages could be inserted at some point during development. The linkages would be identified to include, for example, a common glossary of terms or common reference sources. These types of hyperlinks are generally one-way, meaning that full cross-linkages and cross-referencing could not be implemented. However, by linking to references, definitions, or areas where additional material can be found, this method provides additional functionality beyond what is seen in a traditional document. The hyperlinked PDF would not be navigable in the same way as a web-based delivery; which means that it will be difficult for the Public to work backwards once linkages have been followed. For sustainment, new versions of the SEBoK would be created as traditional document updates occur now. However, it will be critical that the linkage framework and scripts be transferred to the steward organizations. The framework and scripts will have to be updated and applied to new versions of the SEBoK.

Evaluation Criteria• Internal Consistency: Consistency for the hyperlinked PDF option is completely dependent upon quality control. However,

assuming that the document is developed to be internally consistent and that linkages are created following a standardized and controlled process then the consistency should be high.• Stability: Because the document will not be editable, a hyperlinked PDF will be completely stable for each individual

release. It will be easy to differentiate between releases. If the sustainment phase follows current precedent, the SEBoK will likely only be updated once every 3-5 years. Therefore, the overall stability will be considered high.• Semantic Linkages: Because the document will contain hyperlinks, it should allow some level of semantic linkage.

However, it should be noted that this can only be a one-to-one (and often a unidirectional) relationship. For example, in the text it is possible to link a term to its definition, but it is much more difficult to navigate back to the original text containing the term.• Evolution: Evolution of a hyperlinked PDF will be entirely dependent upon the frequency of updates conducted by the

stewards during sustainment. Current precedent indicates that this will be every 3-5 years. Therefore, the evolution will be considered slow.• Access: A PDF is generally a very accessible file format; because there is freeware which allows opening and reading of PDF

documents, there should be no costs to the public associated with access. It should be noted that this does require the stewards to make the document freely available. However, it is only accessible through a single entry point by accessing the document as a whole, where-as wiki content can be accessed from multiple entry points.

Static Wiki

The term “static” refers to the fact that information is presented in a web-based wiki format, but is updated like a traditional document: it is held in one state for a period of time until a formal update is created, at which point a new “version” is published. It should not be taken to mean that there is not a dynamic, semantic linkage between content.

Assumptions•Development efforts for both the Static Wiki and the Evolving Wiki (see 3.3) would be the same•Public could provide comments and feedback without altering the content.•Frequency of update will likely have the largest impact on cost.

Evaluation Criteria• Internal Consistency: Consistency for the Static Wiki option is completely dependent upon quality control. However,

assuming that the wiki is developed to be internally consistent, then the consistency should be high. It also provides the capability to maintain semantic consistency between concepts.• Stability: Because the Static Wiki will be refreshed and updated periodically, it will have a high level of stability.• Semantic Linkages: Because the Static Wiki will contain placeholders for the addition of related topics and can more

easily support one-to-many relationships, the semantic linkages, if properly implemented, should enable efficient and effective navigation of the SEBoK materials.• Evolution: Evolution of the Static Wiki will be entirely dependent upon the frequency of updates conducted by the

stewards during sustainment. Current precedent indicates that this will be every 3-5 years. If this precedent holds, the evolution will be considered slow. However, this may be driven by Public comments, which could increase the periodicity. However, it is unlikely that updates would occur more frequently than every 2 years, so evolution would be lot to moderate.• Access: A Static Wiki model would be web-based, meaning that all individuals should be able to access it. This

requires that access controls be properly used, but if this is done, then the Static Wiki should be fully open to read the content and provide comments, but only authorized individuals could update the content.

Evolving WikiThe term “evolving” refers to the fact that information in the Wiki will be frequently updated. It includes all of the linkages and cross-references of material seen in the Static Wiki option. However, in the Evolving Wiki model, the content would be updated more frequently and would not be updated holistically. For example, updates might be made rapidly to one section, while another section does not change for a long period of time.

Assumptions•Development efforts for both the Static Wiki and the Evolving Wiki (see 3.3) would be the same•Public could provide comments and feedback without altering the content.•Frequency of update will likely have the largest impact on cost.

Evaluation Criteria• Internal Consistency: Consistency for the Evolving Wiki option is dependent upon the level of change. However, if

some content areas are updated while others are not, it is likely that some inconsistencies will be created, either through having outdated information in some areas or through the breakage of semantic linking. It should be noted, however, that this is dependent on how change is controlled and implemented.• Stability: Because the Evolving Wiki could have near real-time changes, it would be considerably less stable than the

Static Wiki.• Semantic Linkages: Because the Evolving Wiki will contain placeholders for the addition of related topics and can more

easily support one-to-many relationships, the semantic linkages, if properly implemented, should enable efficient and effective navigation of the SEBoK materials.• Evolution: Changes to the Evolving Wiki would most likely be rapid. The concept would enable near real-time changes

to content, meaning that the evolution would likely be high. It should be noted, however, that this is dependent on how change is controlled and implemented.• Access: An Evolving Wiki model would be web-based, meaning that all individuals should be able to access it. This

requires that access controls be properly used, but if this is done, then the Static Wiki should be fully open.

Open WikiAn Open Wiki model is one that would allow anyone to edit the content of any page within the wiki structure. For the development phase, this would mean that all authors have access to and can edit all pages of the Wiki. For sustainment, this would mean that the Public would have access to and could edit any content in the Open Wiki.

Evaluation Criteria• Internal Consistency: Consistency for the Open Wiki option is dependent upon the quality control measures in

place. However, as anyone in the Public would be able to modify any content, it is likely that an Open Wiki would quickly develop many internal inconsistencies. For this reason, the consistency of the Open Wiki is considered low. It should be noted, though, that with appropriate governance and a considerable amount of oversight, it could be possible to maintain a more consistent Open Wiki.•Stability: Because the Open Wiki is defined by the ability of anyone to edit content, it would be considered

highly unstable. The only way to ensure stability would be to create an archive of each “release version” of the Open Wiki—this archived version would then become the official, “stable” version. However, in order to avoid confusion, this would have to be kept separately from the Open Wiki. This would like cause too much confusion to be helpful.•Semantic Linkages: Because the Open Wiki will contain placeholders for the addition of related topics and can

more easily support one-to-many relationships, the semantic linkages, if properly implemented, should enable efficient and effective navigation of the SEBoK materials.•Evolution: Because the Open Wiki would be altered in real-time, it would most likely have a considerably high

evolution, assuming that the public utilizes this tool.•Access: An Open Wiki model would be web-based, meaning that all individuals should be able to access it. This

requires that access controls be properly used, but if this is done, then the Static Wiki should be fully open.