WikiDE Contribution Process

This section shows how a WikiDE can realize the requirements Self-administration, Immediate Feedback, and Code Reviews at the same time. A modification of the joining process described in Section 1.1.4 is used to fulfill the seemingly contradictory requirements.

Wikis most often rely on post-commit reviews. Examples are the English, French, and Italian Wikipedias [P*Wik16d]: Even anonymous visitors to these wikis can change the texts and everybody else sees the changes immediately. All users can undo this change. This way, everybody can review any change after it was commited. Sometimes two parties alternately revert each other’s changes. This is called an edit war [P*Wik16b]. Edit wars need to be resolved by administrators, who are wiki users with additional rights. Most often, administrators are not necessary in the review process: There are around three to five percent double reverts per revert in the English Wikipedia [Bur+06].

Wikipedias in some other languages, for example the German and the Russian Wikipedia, use a concept called flagged versions [P*Wik15b]. In the flagged versions concept, every change may or may not be flagged. Users with a special reviewer right can flag or un-flag any change. Anonymous visitors of the wikipedia web site see only flagged changes of articles, while authenticated users can configure whether they want to see unflagged changes. Users of these Wikipedias are automatically given the special reviewer right if they fulfill certain criteria like being authenticated and having made at least 300 edits in the past. Changes made by these users are automatically flagged and visible to all others. If users without the special review right, for example anonymous users, change an article, their changes are not immediately visible to most other users, as their changes are unflagged. Only after a user with the special reviewer right flags the change, it will become visible to everybody else. The concept of flagged versions is intended to reduce vandalism [P*Wik16c]. Flagged versions remove the incentive of vandalism, as the change will not be visible to the general public. Flagged versions therefore provide a method to realize Immediate Feedback while at the same time establishing a process for Code Reviews.

Using the concept of flagged versions for a WikiDE allows Immediate Feedback for newcomers while the core developers can still perform Code Reviews before integrating newcomers’ modifi- cations. On the other hand, the flagged versions concept must be adapted to VCSs before it can be used in software development.

GitHub [P*Git15c] and GitLab [P*Git16c] already use a branching mechanism that realizes some aspects of the flagged versions concept. As described in Section 4.1.2, newcomers can branch a public project into their own repository with a single click. They can thereby modify the source code without prior review by the core developers of the original component. This is isomorphic to the flagged versions concept, if modifications in the original repository are considered flagged and modifications in other repositories are considered unflagged. Most users see only the modifications in the original repository. All users can create unflagged modifications in their own repositories. It requires a special review right to flag a modification or create a flagged change from scratch: The user needs modification rights on the original repository.

However, in order to test modifications, software developers still have to set up a local git client, download the source code to their machines, install and configure a build environment, and build the executable. Therefore, the FLOSS contribution process depicted in Figure 1.3 is still valid when using software forges with a code editor and review system like GitHub. The web-based editor can only be used if the modification is not to be tested, for example if the modification only affects the documentation.

Thus, further adaption of the flagged versions concept is required. The UML activity diagram in Figure 4.1 shows how to adapt the original FLOSS contribution process described in Section 1.1.4 with the flagged versions concept of wikis. The diagram shows how a newcomer modifies source code and how the source code is merged into the primary branch of the VCS. Newcomers modify the source code and test the modified application in their own context within the WikiDE, so they can prepare an atomic modification package. When they are finished, the modifications are stored as private modification package, yet invisible to other software developers using the WikiDE. When newcomers decide to publish their private modification packages, they become public modification packages. Other software developers can review these public modification packages and the core developers can decide to include the modification into the main branch of the application, which is equivalent to flagging the change in the Wikipedia concept of flagged versions.

This contribution process solves the problem of how to fulfill the requirements of Self- administration, Immediate Feedback and Code Reviews at the same time. With this new process, WikiDEs relieve newcomers from the major activities Build the application and Submit a patch of the process in Section 1.1.4. As concluded in Section 2.9, these activities have been shown to be especially frustrating and important contribution barriers, so WikiDEs using the adapted process lower these contribution barriers.

4.1.4 Architecture4

This section describes the components necessary to realize a WikiDE that fulfills the requirements listed in Section 4.1.1. Each of the following subsections describes one component along with

4.1 WikiDE Concept Newcomer WikiDE Core De v elopers Modify source code Test application behavior Build application Publish modification Public modification package Merge modifications to code trunk Review modifications [Application misbehaves] [Application works as expected] [Publish] [Keep private]

[Further modifications necessary]

[Modifications accepted]

references to existing software for its realization.

There are different Wiki systems with textual content that differ in purpose and features. Accordingly, different WikiDEs may differ in purpose and features. Thus, for most of the WikiDE components, there is not just one possible realization. Therefore, each component can be realized with the help of multiple different software solutions, but this analysis does not evaluate which software is the best to realize a particular WikiDE component.

Figure 4.2 shows a UML component diagram of a possible WikiDE architecture. The WikiDE system is a wiki and therefore a web application. The WikiDE system interacts with the software developers via a standard web browser. This standard web browser runs a web-based code editor. The web-based code editor communicates with the web server via a web service to load and save source code as well as load application executables for the software developers to test. On the server side, the web server uses a VCS as the backend to load and save the source code. An additional database stores information about the software developers who have created an account in the WikiDE. This information consists of login data, personal preferences for the user interface, and a configuration of the target environment the software developers want to develop their applications for. The final component is a build system that builds the application executables from the given source code. The software developers can download these application executables to test their changes.

<<subsystem>> WikiDE Server <<component>> Web server <<component>> Version Control System abstraction <<component>> Database abstraction <<component>> Build System control cmp WikiDE system <<subsystem>> Client Browser <<component>> Code Editor <<component>> Wiki logic <<subsystem>> Build Systems <<subsystem>> Database <<subsystem>> Version Control System

Figure 4.2: Proposed Architecture of a WikiDE

Wiki Systems

Section 4.1.2 discussed the features of wiki applications. As shown, both wiki applications and Structured Wikis lack essential WikiDE requirements. Wiki systems may serve as the

4.1 WikiDE Concept foundation for a WikiDE. Other components have to be integrated in the wiki system to satisfy the requirements for a WikiDE.

Web-based Code Editors

Section 4.1.2 described that cloud IDEs let users write code in a web browser and store or execute it on a server. As shown in Figure 4.2, a web-based code editor and therefore a cloud IDE is an essential part of the WikiDE architecture.

Build Systems

A desktop IDE can create debug builds as well as release builds. When debugging the application, the IDE creates a debug build and attaches its debugger to the application executables. Even in a traditional development setting, often dedicated build servers create the release builds. Typically, these dedicated build servers are part of a CI system.

A CI system creates a build for every change in the source code. This uncovers incompatibilities between different software modules quickly, as the CI system shows an error message immediately after the first change that causes the build to fail. Examples for CI systems are Jenkins [P*Jen15] and CruiseControl [P*Cru15].

From the perspective of a cloud IDE, build systems and especially CI systems provide an abstraction for the build process as opposed to executing the build steps manually, e.g. calling the compiler and linker directly from the cloud IDE. Building the application executables with the help of a CI system has two advantages over executing the build steps directly: First, existing CI systems support various build configurations like programming languages and target platforms already. If a cloud IDE executed the build steps manually, the software developers of the cloud IDE would have to invest time for each supported build configuration. Second, CI systems like Jenkins and CruiseControl already provide a web interface to control the build process. Software developers using the cloud IDE use the browser to access both the cloud IDE as well as the CI system.

The proposed WikiDE therefore uses a CI to build the application executables, but the CI is controlled by the WikiDE logic instead of the users directly. When WikiDE users modify the source code, the CI provides executable versions of the modified component immediately. This satisfies the Immediate Feedback requirement.

Debuggers

There are two machines involved in the debugging process. The first is the development machine, which hosts the source code and displays the current state of the application. The other is the test machinethat actually executes the application. A developer using a desktop IDE usually runs the application on the same machine that runs the IDE, so the two machines are identical. The WikiDE web interface displays the source code, allows editing, and consequently should display the application’s state when debugging the application. Thus, the web server running the WikiDE web application is the development machine. This web server might run on a platform different to the intended target platform of the application. At least in this case, the development machine must be different to the test machine.

The architecture of the WikiDE and the debugging scenario differs depending on where the test machine is placed. There are two possibilities for the placement of the test machine: First, the developers provide test machines themselves, possibly the same machines they are running their web browsers on. In this case, the developers must execute a remote debugger on the test machines in addition to the application itself. The remote debugger transfers the application’s state to the development machine, where it is displayed via the WikiDE web interface. The developers interact with the application directly. Thus, the test machine is placed on the client side, the developer is responsible for its operation. Second, the WikiDE provides a test machine on the server side. The test machine’s input and output are redirected to the WikiDE web interface. The developer interacts with the test machine via the WikiDE web interface. If the application has a GUI, the test machine’s display output can be shown using a web-based remote desktop application like TightVNC Java Viewer [P*Tig09] or even an AJAX-based RDP client like AJAX Remote Desktop Viewer [P*Dam06]. This realizes a debugger for the Immediate Feedback requirement. Abbasi et al. [ASP10] have shown the feasibility of this approach with their tool XYLUS.

Version Control Systems

Distributed VCSs like git [P*git16] and hg [P*Mer16] create a new branch of versions every time a new development machine downloads the source code. They merge two branches of versions every time a change set is uploaded to a server hosting a distributed VCS [OSu09]. Therefore, multi-dimensional version lists become more common with the advent of distributed VCSs.

Using the one dimensional list of historic versions provided by most wiki systems for a WikiDE contradicts the requirement Version Control System. Using the version history of a wiki system is also not compatible with most existing VCSs, so it is more difficult to use a WikiDE and a desktop IDE in parallel. As described in Section 4.1.2, some wiki applications use a VCS as backend and therefore fulfill the IDE Compatibility requirement. They still have a one-dimensional version history, so additional changes to such a wiki application are required before it fulfills the requirement Version Control.

The software forge services GitHub [P*Git15c] and GitLab [P*Git16c] provide web-based access to its hosted git VCSs. They automatically fork repositories into a user’s space on modifications. This can be seen as a step towards the realization of the contribution process described in Section 4.1.3.

Issue Trackers

Code reviews can be realized with an issue tracker or with a specialized review system. One possibility to realize a review process with an issue tracker is the following: Users and software developers of an application can create tickets in the issue tracker. These tickets describe defects or feature requests. Software developers can then submit patches containing source code modifications and attach these patch files to the corresponding tickets. If core developers positively review the patch files, they will be committed to the main VCS branch. Examples for issue trackers are Mozilla Bugzilla [P*Moz01] and Atlassian JIRA [P*Atl16].

4.2 CI Services