ویکی Scaffolding:ویکی های هم ردیف و موازی با استراتژی شرکت های بزرگ

Wikis are main exponents of collaborative development by user communities. This community may be created around the wiki itself (e.g., community of contributors in Wikipedia) or already exist (e.g., company employees in corporate wikis). In the latter case, the wiki is not created in a vacuum but as part of the information ecosystem of the hosting organization. As any other Information System resource, wiki success highly depends on the interplay of technology, work practice and the organization. Thus, wiki contributions should be framed along the concerns already in use in the hosting organization in terms of glossaries, schedules, policies, organigrams and the like. The question is then, how can corporate strategies permeate wiki construction while preserving wiki openness and accessibility? We advocate for the use of “Wiki Scaffoldings”, i.e., a wiki installation that is provided at the onset to mimic these corporate concerns: categories, users, templates, articles initialized with boilerplate text, are all introduced in the wiki before any contribution is made. To retain wikis' friendliness and engage layman participation, we propose scaffoldings to be described as mind maps. Mind maps are next “exported” as wiki installations. We show the feasibility of the approach introducing a Wiki Scaffolding Language (WSL). WSL is realized as a plugin for FreeMind, a popular tool for mind mapping. Finally, we validate the expressiveness of WSL in four case studies. WSL is available for download.

Companies are increasingly realizing the benefits of wikis [1]. Indeed, the Intranet 2.0 Global Survey reports that around 61% of the respondent companies (1,401 participants) were somehow using wikis [2]. As any other Information System, the interplay of technology, work practice, and organization is paramount to achieve successful wiki deployments. Therefore, we can expect differences in wikis depending on the hosting organization, let this be an open community (e.g., Wikipedia), a learning organization [3] or a company [4]. The peculiarities of each organization will certainly percolate the wiki. Documentation, organigrams, project milestones are all there by the time the wiki is created. This contrasts with open wikis (e.g., Wikipedia) where the community did not exist prior to the wiki. As a result, corporate wikis (i.e., wikis host by an existing organization) might be tuned at the onset to the already existing information ecosystem. This is the assumption behind “Wiki Scaffolding”. Next paragraphs introduce the “what”, the “why” and the “how” of this term. What: “Wiki Scaffolding” stands for a wiki installation (a.k.a. a wiki project) that is available from the wiki's onset, before any contribution is made. Such installation mirrors the practices of the hosting organization. Some examples follow: (1) company schedulings might impact the pace at which wiki articles are provided (e.g., deadlines, project milestones); (2) products, services, customers or established terminology within an organization might become categories to classify wiki articles; (3) employees eligible to contribute, and their access control permissions, might be based on the company's organigram. A “Wiki Scaffolding” captures this setting as a wiki installation where the basic wiki configuration might be extended (through plugins) based on the selected scaffolding features (e.g., a plugin for events and calendars). Why: The fact that wikis facilitate knowledge creation does not imply that such knowledge comes out of the blue. Both, the paralysis of facing an empty article and the lack of a holistic view of the wiki content, might prevent grassroot initiatives from “getting off” the ground. At this respect, scaffolding brings three main benefits: 1. Scaffolding facilitates wikis to be better aligned with the organization strategy. Wikis are frequently a bottom-up phenomenon whereby the wiki is introduced by an individual employee or a small group within the organization without the support of management. This approach may be useful to uncover hidden knowledge or hidden ways-of-working in a dynamic and unplanned way. However, it might fail in having a strategic intent. A lack of strategy might result in no clear guidelines about what, how and who should contribute. If so, “Wiki Scaffolding” forces to think about these concerns right from the beginning. 2. Scaffolding promotes user engagement. In a corporate setting, a wiki article might require some permissions, be subject to a deadline, belong to some wiki categories, or follow a given template. All these aspects might not be directly related with the article's content as such, yet they frame the contribution. Setting this frame is cumbersome and delays users in putting their wheels in motion (e.g., start to edit the article). “Wiki Scaffolding” permits this frame to be available by the time contributors start their articles. 3. Scaffolding as a wiki map. The “rules of practice” that govern a site (i.e., roles, access rights, templates, etc.) should be easily accessible to newcomers. So far, this information is scattered around the wiki, and frequently hidden in administrative pages. At best, a README page can provide some textual description of these practices. “Wiki Scaffolding” can play the role of an initial “practice sitemap”. Newcomers can consult the scaffolding to have an eye-bird view of the rules that govern the wiki's operation. How: “Wiki Scaffolding” faces two main obstacles. First, it implies an upfront investment before any content is provided. Second, it requires knowledge about the wiki engine (e.g., MediaWiki) and third-party extensions, both outside the competences of the layman. This will make “Wiki Scaffolding” yet another burden for the organization's IT department since most users will lack the required skills. Akin to the wiki spirit, the scaffolding should be managed by the users on their own. Therefore, both cost-effectiveness and end-user affordability are main prerequisites for scaffolding to be adopted. This advocates for the use of Domain-Specific Languages (DSLs) [5]. Furthermore, collaboration and easy sharing can be promoted by using graphical DSLs (as opposed to textual DSLs). Mind maps are popular diagrams that capture ideas around a central topic [6]. We capitalize from this popularity, and introduce a DSL described as a mind map to both capture and enact “Wiki Scaffoldings”. In short, this paper addresses the following research question: how can corporate strategies permeate wiki construction while preserving wiki openness and accessibility? To this end, we introduce the notion of “Wiki Scaffolding”, and advocate for the use of DSLs as the engineer means. Specifically, we introduce the Wiki Scaffolding Language (WSL) (pronounced “whistle”). WSL is built on top of FreeMind [7], a popular, open source tool to create mind maps. You create your scaffolding by drawing mind maps. Next, you can “export” your mindmap as a “Wiki Scaffolding”: a new wiki is created along the lines of the directives of the scaffolding (see a video of WSL at work at http://vimeo.com/31548363). The source code, examples and installation instructions can be found at http://www.onekin.org/wsl. Alternatively, WSL source code is also available in the official FreeMind repository http://bit.ly/xsA040. This paper is organized along the design and use of WSL: WSL analysis ( Section 2), WSL design ( Section 3), WSL usage ( Section 4) and WSL at work ( Section 5). Conclusions end the paper.

We introduce the notion of “Wiki Scaffolding” as a means for corporate strategies to permeate wiki construction. We realize “Wiki Scaffolding” as mind map drawing to preserve wikis’ openness. The result is WSL, a graphical DSL on top of FreeMind. By taping into FreeMind as the conduit for the WSL concrete syntax, we expect non-technical communities to benefit from scaffolding. Potential benefits include facilitating the alignment of the wiki with organizational practices, promoting management engagement, enhancing the visibility of the wiki's practices, or promoting employee participation through direction setting. WSL constructs are based on a literature survey about the use of wikis in companies. However, the use of corporate wikis is at its inception. It is likely that social conventions and incentives will emerge and evolve to guide contributors, resolve disputes and help manage wikis. As these issues find support in wiki engines, WSL constructs will need to be extended. In addition, we have so far focused on the feasibility of the approach and its interest in different scenarios. Additional evidences are needed to claim scaffolding succeed on better aligning wikis to corporate strategies as well as engaging users through direction setting. We plan to deploy WSL in organizations that have already been exposed to wikis to collect evidences about the advantages brought by the scaffolding. In so doing, we hope to introduce scaffolding as another step in the wiki ideal of removing “accidental complexity” from technology, and letting ordinary users directly manage and construct their own knowledge.