monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Preparing for docathon


From: Hendrik Boom
Subject: Re: [Monotone-devel] Preparing for docathon
Date: Sat, 18 Dec 2010 14:17:42 -0500
User-agent: Mutt/1.5.18 (2008-05-17)

On Sat, Dec 18, 2010 at 05:03:24PM +0100, Richard Levitte wrote:
> Hi,
> 
> A few words about the upcoming docathon.
> 
> Thomas Keller is the initiator and thereby has a natural leading
> role.  However, he might not be part of part of the effort tomorrow
> evening and has therefore asked me to be a stand in.
> 
> I will be present on IRC most of the time (huge exception for early
> afternoon tomorrow), and especially tomorrow (Sunday) from 16ish to
> midnight UTC.
> 
> The thoughts below are what we have come up with for now.  If you have
> a pet doc thing you'd like to see included, please tell us!
> 
> 
> ========
> The wiki
> ========
> 
> I've done some preparations for this weekend's docathon, at least with
> the wiki.  All pages have been tagged 'needs-reviewing', and those are
> the first that one should look at.  The first effort is to do a quick
> job; if you can do a minor fix on a page, do it, but otherwise, the
> job is initially meant to categorise the pages.  This is done by
> changing the tag 'needs-reviwing' to one of the following:
> 
>   * 'reviewed-ok' would mean it was ok, or minor fixes were made so it
>     is now ok.
>   * 'reviewed-delete' would require confirmation from a second
>     reviewer; if they agree, they could simply delete the file.
>   * 'reviewed-needs-work' means that some work has been done, but it
>     needs more than we want to handle at the moment. Hopefully, such
>     pages will be rare, or at least temporary.
> 
> 
> The wiki page http://wiki.monotone.ca/Review/2010/ contains the lists
> of pages marked 'needs-reviewing', 'reviewed-needs-work',
> 'reviewed-delete' and 'reviewed-ok', and gets updated everytime one of
> those tags are changed (just make sure to reload it).  it should
> therefore be pretty easy to just pick a page to work with.
> 
> The next step, which can happen in parallell, is to take on the pages
> that are tagged 'reviewed-needs-work' and work with it.  If you don't
> know what to do with it or need ideas/inspiration, please just ask on
> IRC.  One most notable page that really needs work is the front page
> (http://wiki.monotone.ca).  That one's worth talking about!
> 
> 
> ==========
> The manual
> ==========
> 
> Various work is needed here.
> 
> Someone could check that all commands are present in the manual
> (remember, 0.99 has quiet a number of changes and additions) so
> nothing is forgotten.  Making sure we have a complete reference
> section would be awesome!
> 
> Some commands in the command section might need more examples.  If you
> have something you wish for, please say so, and if you're inclined,
> please offer a patch or commit a change.  This doesn't have to be big,
> small examples are usually good!
> 
> Some sections of the manual could really be moved to the wiki.  The
> most notable example is the mark-merge discussion.
> 
> 
> ======
> Source
> ======
> 
> INSTALL would need to be split by platform.
> README would need a bit more text, a short presentation of monotone,
> so people starting there can get to know what they just downloaded!
> 
> 
> =====
> Other
> =====
> 
> Someone could write up 5 minute intros to monotone.  "mtn for git
> users", "mtn for svn users", and so on.  Maybe this belongs in the
> manual, maybe on the wiki, maybe on monotone's main web page
> (http://monotone.ca).  It doesn't really matter where we put them
> tight now, the most important is that they get written and committed
> somewhere!

The reverse would also be useful -- svn for mtn users, and the like.  I 
often have to use or contribute to a project that uses svn or git, 
though my own inclination is to use mtn.

Knowing how to coordinate mtn and other use would be especially sweet -- 
maintinaing my own development on such a project in mtn (on multiple 
machines) and, when the time comes, issue the commands to check them 
in or our of svn or git, and sync with headquarters.

Or just maintianing an svn vendor branch whilc I use mtn.

Doing all this is probably more complex than just indicating what scn 
and git commands correspond to mtn ones, though.

-- hendrik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]