I don't think canonical would either, i will let you guys know what happens with the other manual in terms of a sprint. The thing with the other manual's sprint is that there are only about 7-8 of us who are working on it, some of those people are Aq, Rick Spencer, Didier Roche, me, another guy who's name i cant remember and Michael Terry, so i think we have a good chance of getting funded, because of the small amount of people.
Ryan Macnish On Mon, Nov 1, 2010 at 10:09 AM, Benjamin Humphrey <humphre...@gmail.com>wrote: > Ryan, > > A canonical funded sprint would be totally kickass but I'm not sure we can > convince them to pay for it at this stage. Would be awesome though. > > Benjamin > > interesting.co.nz > ohso.co > On 1/11/2010 1:13 PM, "Chris Woollard" <cwooll...@gmail.com> wrote: > > That would probably be useful. > > > > I am up for it. > > > > Chris > > > > > > > > > > On 1 November 2010 00:09, Ryan Macnish <nisshh.ubu...@gmail.com> wrote: > > > >> Oh yeah guys, i forgot to mention what happened at the UDS-N session for > >> the developer manual (i was remote participating), one of us there > suggested > >> that we have a face-to-face canonical funded sprint sometime this cycle. > >> What do you guys think about that? > >> > >> Ryan Macnish > >> > >> > >> On Mon, Nov 1, 2010 at 7:34 AM, Chris Woollard <cwooll...@gmail.com > >wrote: > >> > >>> All I know is that I have tried really hard to get people to help out. > >>> Sure, I have had my own life to deal with as well (Which has also be > busy), > >>> so I have not always been around. But I have tried to get people to > help > >>> edit / proof read. I have even posted new builds of the pdf after > changes > >>> have been made. I have to say that it really feels like I have been > doing > >>> most of the work myself :( This is quite de-motivating. > >>> > >>> It would really be great if things could be turned around. With the > Lucid > >>> release it really felt like we were all working as a team. With > Maverick, > >>> that has just not happened. Dare I say it, but the manual project kind > of > >>> feels orphaned. > >>> > >>> I hope things can change. > >>> > >>> All the best > >>> > >>> Chris > >>> > >>> On 31 October 2010 23:16, Ilya Haykinson <haykin...@gmail.com> wrote: > >>> > >>>> So in conclusion, i don't think we should release less often, we > should > >>>>> just work to improve our workflow and the workflow of new > contributors > >>>>> whether they be authors, editors or translators. Also i do remember > that > >>>>> Ilya was around a lot during the lucid cycle sort of being an editor > in > >>>>> chief, but since then we haven't had anyone doing that. > >>>>> > >>>>> > >>>> I've been keeping up with the mailing list traffic, but have been very > >>>> busy at work for the last 5 months or so -- so much so that I couldn't > >>>> really contribute to the Maverick release. I completely agree that the > main > >>>> thing that is required is some small group of people who serve as the > >>>> editors and drive the process along -- making decisions on where to > cut and > >>>> where to focus, etc. Obviously I couldn't spare the time for the > Maverick > >>>> cycle, and am not yet sure how the Natty cycle will look for me (the > first > >>>> couple of months are going to be tough for sure). > >>>> > >>>> However, I think it's critical to release every 6 months, even if the > >>>> quality isn't great. Only through frequent releases combined with > small > >>>> improvements can the end product end up great -- if you take 2 years > to do a > >>>> release, I think the team will fall apart. > >>>> > >>>> My recommendations are (some are the same as what others have > >>>> recommended): > >>>> > >>>> - manage translations separately, and do not release the manual to > >>>> translators until after the manual is ready to go. this will yield a > >>>> smoother translator experience as the content won't be changing from > under > >>>> them, and will simplify the manual itself. > >>>> - delay the manual publishing date for 3-5 weeks after each release, > to > >>>> allow content and screenshots to catch up > >>>> - by beta1, have a firm list of changes to be included in the manual; > a > >>>> week after release date, cut anything that hasn't been written or is > >>>> possible to get to the highest quality. > >>>> - work to improve the process. I think this is the least important > item, > >>>> honestly, since core contributors will always be ok with downloading > TeX and > >>>> dealing with compilation etc, and while it's key for long-term project > >>>> health to bring in casual contributors, I think that a) this is a > >>>> stand-alone process that shouldn't be mixed into shipping the manual > itself, > >>>> and b) the manual comes first, well before automation or better > processes. > >>>> > >>>> Thoughts? > >>>> > >>>> -ilya > >>>> > >>>> > >>>> _______________________________________________ > >>>> Mailing list: https://launchpad.net/~ubuntu-manual > >>>> Post to : ubuntu-manual@lists.launchpad.net > >>>> Unsubscribe : https://launchpad.net/~ubuntu-manual > >>>> More help : https://help.launchpad.net/ListHelp > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Mailing list: https://launchpad.net/~ubuntu-manual > >>> Post to : ubuntu-manual@lists.launchpad.net > >>> Unsubscribe : https://launchpad.net/~ubuntu-manual > >>> More help : https://help.launchpad.net/ListHelp > >>> > >>> > >> >
_______________________________________________ Mailing list: https://launchpad.net/~ubuntu-manual Post to : ubuntu-manual@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-manual More help : https://help.launchpad.net/ListHelp
