Simple commit mechanism for non-technical users

Simple commit mechanism for non-technical users

[D Sundstrom]

I use git to manage all project artifacts, including documentation,
proposals, presentations, and so on.

However, I have a hard time convincing non-technical staff to learn
enough about git or to take the time to go through the effort of
committing changes to a repository.  So the steady stream of email
attachments with "Acme Specification v3" or "final final spemco
proprosal" continues.

I'd hoped there was a simple web interface that would allow a user to
upload and commit a file to a repository, but I've had no luck finding
one.  (I've used cgit for browsing, but it is read-only).

Is anyone aware of a simple way I can have my non-technical users
manage their documents against a git repository?  Ideally this would
involve no installation of software on their machine (unless it were
compelling, for example, the Finder plugin for SVN on the mac was a
great tool for these users; or at least those on a mac...)

-David

Re: Simple commit mechanism for non-technical users

[Chris Packham]

On Wed, Aug 19, 2009 at 4:05 AM, D Sundstrom<sunds@peapod.net> wrote:
> I use git to manage all project artifacts, including documentation,
> proposals, presentations, and so on.
>
> However, I have a hard time convincing non-technical staff to learn
> enough about git or to take the time to go through the effort of
> committing changes to a repository.  So the steady stream of email
> attachments with "Acme Specification v3" or "final final spemco
> proprosal" continues.
>
> I'd hoped there was a simple web interface that would allow a user to
> upload and commit a file to a repository, but I've had no luck finding
> one.  (I've used cgit for browsing, but it is read-only).
>
> Is anyone aware of a simple way I can have my non-technical users
> manage their documents against a git repository?  Ideally this would
> involve no installation of software on their machine (unless it were
> compelling, for example, the Finder plugin for SVN on the mac was a
> great tool for these users; or at least those on a mac...)
>
> -David
> --

Actually this is one situation that I'd say there are better solutions
than git _ducks_.

The solution I've been trying to push people toward at my day job is
using a wiki (we chose mediawiki but all the extra markup might still
scare non-techies). Wiki's are version controlled (in a simple,
centralized fashion) and allow editing from multiple authors and can
be updated quickly. The only client software you need is a web
browser. Plenty of open source projects use wikis for their living
specifications.

You may also want to look around for other content management systems
but the only one I've used kinda sucked. Not sure if there are any
good open source ones (but then again I haven't really looked).

If you still want to use git as your version control system for these
kinds of documents it shouldn't actually be too hard to implement and
simple uploader to complement a viewer like cgit or gitweb.
Unfortunately I don't know of any that exist but maybe someone else on
the list does.

Re: Simple commit mechanism for non-technical users

[Johannes Schindelin]

Hi,

On Tue, 18 Aug 2009, D Sundstrom wrote:

> I use git to manage all project artifacts, including documentation, 
> proposals, presentations, and so on.
> 
> However, I have a hard time convincing non-technical staff to learn
> enough about git or to take the time to go through the effort of
> committing changes to a repository.  So the steady stream of email
> attachments with "Acme Specification v3" or "final final spemco
> proprosal" continues.
> 
> I'd hoped there was a simple web interface that would allow a user to
> upload and commit a file to a repository, but I've had no luck finding
> one.  (I've used cgit for browsing, but it is read-only).
> 
> Is anyone aware of a simple way I can have my non-technical users
> manage their documents against a git repository?  Ideally this would
> involve no installation of software on their machine (unless it were
> compelling, for example, the Finder plugin for SVN on the mac was a
> great tool for these users; or at least those on a mac...)

You contradict yourself here, the Finder plugin needs to be installed, and 
SVN, too.

As for your problem: I think you need a specific solution.  If I 
understand you correctly, files which have the same name (but maybe a 
suffix "v3" or similar before the extension), and they should be 
committed to a Git repository.

Then you have a bunch of people who do not want to care about learning 
proper version control.

This is what I would do: write a very simple .cgi (I'd use Perl for that), 
which has a file upload button, takes the name as commit message (or maybe 
adds a field where you can type in a commit message, but that might be 
asking your bunch of Aunt Tillies too much), strips the "v3"-like suffixes 
($name =~ s/[-_ ]*v\d+(\.[A-Za-z0-9]{1,5})$/$1/;), set author and 
committer information according to IP (and refuse if the IP is not in the 
internal mapping) and commit.

The whole script would probably not be larger than 50 lines, and require 
Git to be installed on the server.

The bigger problem is that your Aunt Tillies most likely would not love 
gitweb, so you need a fancier interface.

Ciao,
Dscho

Re: Simple commit mechanism for non-technical users

[Matthieu Moy]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Then you have a bunch of people who do not want to care about learning 
> proper version control.

OTOH, my experience with non-technical people and revision control is:
they send you an email with the file attached, saying they promise
they will learn the tool one day, but not right now because they don't
have time, and then you have to find out how to merge and commit
yourself.

And unfortunately (also from my experience), this is not limited to
non-technical people ...

For this category of people, a simple web-based commit tool will not
teach them anything (which is bad), but at least reduces the work of
the technical guys (which is somehow good).

-- 
Matthieu

Re: Simple commit mechanism for non-technical users

[Jeff King]

On Wed, Aug 19, 2009 at 09:49:50AM +0200, Johannes Schindelin wrote:

> Then you have a bunch of people who do not want to care about learning 
> proper version control.
> 
> This is what I would do: write a very simple .cgi (I'd use Perl for that), 
> which has a file upload button, takes the name as commit message (or maybe 
> adds a field where you can type in a commit message, but that might be 
> asking your bunch of Aunt Tillies too much), strips the "v3"-like suffixes 
> ($name =~ s/[-_ ]*v\d+(\.[A-Za-z0-9]{1,5})$/$1/;), set author and 
> committer information according to IP (and refuse if the IP is not in the 
> internal mapping) and commit.
> 
> The whole script would probably not be larger than 50 lines, and require 
> Git to be installed on the server.
> 
> The bigger problem is that your Aunt Tillies most likely would not love 
> gitweb, so you need a fancier interface.

Actually, I think there is a technical problem here. You get Aunt
Tillie's v3, but you don't necessarily know what it is based on. So if
some other Aunt Tillie has submitted a v3 in the meantime, what do you
do with her file? Commit on top? Try to guess where her v2 was, branch
from there, and merge?

If you commit on top, then you are potentially erasing the other
person's work. If you do a merge, you are likely to get conflicts
(especially because Aunt Tillie likes to use horrible binary formats)
that _somebody_ will have to resolve.

I guess you can throw each Tillie on their own branch and then let
somebody clueful do the merging, but then you do not really have people
working together.

I think this is a fundamental issue. Most version control systems (and
especially distributed ones) are about doing concurrent work and
merging, and merging requires a bit of a clue. The Aunt Tillies of the
world really need a locking system to manage concurrency.

-Peff

Re: Simple commit mechanism for non-technical users

[D Sundstrom]

Thanks to all that responded.

It might help to frame things from Aunt Tillie's point of view.
Her workflow consists of editing office documents (word, powerblower, etc)
in collaboration with her peers.  They email these back and forth and
come up with whatever ad-hoc "version control" they think of at the
moment, such as file names, dates, verbal communication, etc.

I'm technical product manager and I need to coordinate reviews of
these documents as well as my release process.  I also face audits
and accreditation from my customers.

We previously chose and implemented GIT for our scm system based
on a number of considerations. Primarily we have distributed teams and
also there is a review and sign-off process before code is "blessed" into
our official repository.  For this, GIT fits well.

I'm going to put all the project artifacts into this repository, including
the aforementioned office documents.  They just get versioned as binary
blobs, which is fine for this application.  I just need to know which one
is current and maintain prior versions.

Aunt Tillie may someday appreciate our scm enough to install a client
on her machine and learn how to use it.  But that is a big jump from
the simple workflow she has today.  My thought is that I might get her
to upload this document to a SMB/CIFS or webdav file share, or use
a simple webapp, but that is about it for now.

My thought is to just have a process that watches for these files and
commits them as they arrive.  I wouldn't do any filename magic, I would
just train Aunt Tillie to use the same name every time.  If two people
step on each other's work, they tend learn from the experience and
coordinate amongst themselves the next time.  There are only a
few people touching any given document.

A wiki doesn't seem appropriate because we are dealing with office
documents rather than "wiki-like" content.  This is more of a
document management system, albeit a very simple one.

The Aunt Tillies are all on windows (XP or later).  The development
team is all over the map, windows, osx, linux.

-David


On Wed, Aug 19, 2009 at 5:20 AM, Jeff King<peff@peff.net> wrote:
> On Wed, Aug 19, 2009 at 09:49:50AM +0200, Johannes Schindelin wrote:
>
>> Then you have a bunch of people who do not want to care about learning
>> proper version control.
>>
>> This is what I would do: write a very simple .cgi (I'd use Perl for that),
>> which has a file upload button, takes the name as commit message (or maybe
>> adds a field where you can type in a commit message, but that might be
>> asking your bunch of Aunt Tillies too much), strips the "v3"-like suffixes
>> ($name =~ s/[-_ ]*v\d+(\.[A-Za-z0-9]{1,5})$/$1/;), set author and
>> committer information according to IP (and refuse if the IP is not in the
>> internal mapping) and commit.
>>
>> The whole script would probably not be larger than 50 lines, and require
>> Git to be installed on the server.
>>
>> The bigger problem is that your Aunt Tillies most likely would not love
>> gitweb, so you need a fancier interface.
>
> Actually, I think there is a technical problem here. You get Aunt
> Tillie's v3, but you don't necessarily know what it is based on. So if
> some other Aunt Tillie has submitted a v3 in the meantime, what do you
> do with her file? Commit on top? Try to guess where her v2 was, branch
> from there, and merge?
>
> If you commit on top, then you are potentially erasing the other
> person's work. If you do a merge, you are likely to get conflicts
> (especially because Aunt Tillie likes to use horrible binary formats)
> that _somebody_ will have to resolve.
>
> I guess you can throw each Tillie on their own branch and then let
> somebody clueful do the merging, but then you do not really have people
> working together.
>
> I think this is a fundamental issue. Most version control systems (and
> especially distributed ones) are about doing concurrent work and
> merging, and merging requires a bit of a clue. The Aunt Tillies of the
> world really need a locking system to manage concurrency.
>
> -Peff
>

Re: Simple commit mechanism for non-technical users

[Jakub Narebski]

D Sundstrom <sunds@peapod.net> writes:

> I use git to manage all project artifacts, including documentation,
> proposals, presentations, and so on.
> 
> However, I have a hard time convincing non-technical staff to learn
> enough about git or to take the time to go through the effort of
> committing changes to a repository.  So the steady stream of email
> attachments with "Acme Specification v3" or "final final spemco
> proprosal" continues.
> 
> I'd hoped there was a simple web interface that would allow a user to
> upload and commit a file to a repository, but I've had no luck finding
> one.  (I've used cgit for browsing, but it is read-only).

Some of git web interfaces or git hosting software offer editing via
web interface.  Neither gitweb nor cgit offers this; it is available
AFAIK in GitHub (but it is not open source, and server version GitHub:FI
isn't cheap).

You can use some wiki (there are some wikis with git backend,
e.g. ikiwiki, see http://git.or.cz/gitwiki/InterfacesFrontendsAndTools)
or CMS like Drupal instead.  Note that wikis usually work in 
lock-edit-unlock mode (no merging changes), and have per page (per file)
versioning.


Alternate solution would be to use one of GUIs for Git, like
e.g. git-gui or QGit, or filemanager integration / shell extension
like (for MS Windows) TortoiseGit or Git Extensions.

> Is anyone aware of a simple way I can have my non-technical users
> manage their documents against a git repository?  Ideally this would
> involve no installation of software on their machine (unless it were
> compelling, for example, the Finder plugin for SVN on the mac was a
> great tool for these users; or at least those on a mac...)

What operating system?  What do you use currently?

-- 
Jakub Narebski
Poland
ShadeHawk on #git