user-classifications.html [plain text]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<style type="text/css"> /* <![CDATA[ */
@import "branding/css/tigris.css";
@import "branding/css/inst.css";
/* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
href="branding/css/print.css"/>
<script type="text/javascript" src="branding/scripts/tigris.js"></script>
<title>User Classifications</title>
</head>
<body>
<div class="h2">
<h2>User Classifications</h2>
<p>In use case lingo, the typical <em>actors</em> for our version
control scenarios. The following list provides rough classifications
for the type of individual users driving our requirements.</p>
<div class="h3" id="novice">
<h3>Novice</h3>
<p>A developer inexperienced with version control, your typical
documentation writer, or non-technical user (e.g. pointy-haired
manager, administrative assistant, etc.). Able to make commits, but
often lacking enough understanding of version control concepts to
check out or switch to a branch. Sometimes does creative things like
"delete large chunks of the repository" or "commit a merge
conflict".</p>
</div> <!-- novice -->
<div class="h3" id="developer">
<h3>Developer</h3>
<p>A software professional familiar with most of the basic concepts
used with a typical version control system (e.g. repositories,
workspaces, etc.), including change management (e.g. commit, revert,
merge, patch, conflict resolution, etc.).</p>
</div> <!-- developer -->
<div class="h3" id="merge-meister">
<h3>Merge Meister</h3>
<p>A version control master, usually involved in all important
branching/merging activities, and often responsible for release
engineering. Usually involved in auditing the changes in a branch,
and process enforcement. Often proficient with multiple version
control systems.</p>
</div> <!-- merge-meister -->
<div class="h3" id="program">
<h3>Other Program</h3>
<p>Other programs which invoke Subversion's functionality. These are
often scripts wrapped around the command-line binaries (e.g. for SCM
automation, integration, etc.), which are sometimes APIs in their own
right. They're also often third party programs built on top of
Subversion, integrated with its core libraries at the API level.</p>
</div> <!-- program -->
</div> <!-- h2 -->
</body>
</html>