[Qgis-community-team] Re: Planning for QGIS 1.0.0 '????'

[Tim Sutton]

Hi Tara

2008/7/28 Tara Athan <tara_athan at alt2is.com>:
> Time pressure leads to panic, panic leads to mistakes.

Right - first rule of QGIS project participation is 'Don't panic' :-)
That said occasional time pressues also tend to spur developers on -
before we started out with our more or less two monthly release
programme we had long lags in development because of the absence of
that occasional deadline.

> I think we will be much better off having a looser schedule for the user
> guide and not expect a simultaneous release.

Good.


>
> If we were following a stricter development process (GUI design which is
> specified early, strong communication channels concerning any changes to
> that design) then it might be possible to develop the user guide in parallel
> to the implementation.

I think post 1.0 we will have this, but there are too many competing
interests at the moment e.g. desire to get features in under the 1.0
threshold versus desire to document, versus Gary's desire to have
release 1.0 ready for FOSS4GEO2008. I think we have pretty strong
communication in the project but things can always be improved I
guess. If you look over the past year of the project you will see that
we have taken many steps to formalise the development process e.g.
forming PSC, forming release team, community team, compiling release
checklists, documenting procedures on wiki etc. In the 'old' days we
used to say 'Hey Gary lets do a release there are some nice new
features on board' and the next day he would hatch a new release. Part
of managing the process well is to be pragmatic and realise when we
cant meet goals, then develop workarounds / new ways to manage the
tasks. In past software projects I have worked on having things set
too tightly (e.g. immovable milestones) in stone was a sure fire
recipe for disaster. Ok I'm rambling now.... :-)


> But my feeling is that is not the way this (or any opensource?) project
> works, yes?
>

I think it is a mischaracterisation to say open source is 'sloppy'
development, closed source is rigorous. In reality (well from my
experience) closed source has the same issues, but it happens behind
closed doors so the average Joe doesnt hear about it when schedules
get into flux. We are going through a mutual learning curve (its the
first time we do a major version release, first time we try to
coordinate it with the community team etc). and what we experience now
will help us to make better decisions next time around. I'm sure by
the time we release QGIS 10.0.0 it will be a highly tuned process :-)

Many thanks for your help as always.

Regards

Tim

> Tara
>
> Tim Sutton wrote:
>>
>> Tara and others concerned with the manual
>>
>> The more I think about it, the more I think its maybe not a good idea
>> to try to do simultaneous release of QGIS 1.0 and the manual. I've
>> been going through the bug queue and many of the tickets would require
>> (usually small) changes to the user interface to resolve. This along
>> with Toms work on menus and the GRASS work I am doing and the merge of
>> composer and labelling stuff - and possibly Godofredo's work is going
>> to make a moving target. Trying to restrict UI changes is going to
>> hamper developers, not restricting UI changes is going to hamper doc
>> writers. For this reason I would like to suggest pushing back the
>> manual schedule by a period that will comfortably allow you to update
>> it after the GUI is frozen. What do you and community team think about
>> this?
>>
>> Regards
>>
>> Tim
>>
>> 2008/7/26 Tom Elwertowski <telwertowski at comcast.net>:
>>
>>>
>>> Tara Athan wrote:
>>>
>>>>
>>>> Tim & Tom - Let me see if I have this straight
>>>> 1. items currently in the dropdown menus will probably not be moved to
>>>> different menus, although the order in which they appear might change
>>>>
>>>
>>> Lots of items will be added. A Mac standard is to have every command in a
>>> menu so that an app is fully usable with no visible toolbars. I'd like to
>>> minimize movement so as not to confuse existing users however meaningful
>>> groupings will take precedence over existing position.
>>>
>>>
>>>>
>>>> 2. tools currently in the toolbars may be moved to different toolbars,
>>>> and
>>>> the order may change
>>>>
>>>
>>> There will probably be less change here because most or all commands are
>>> already in toolbars. A few items may be reordered so that the order is
>>> the
>>> same for both the menu and toolbar.
>>>
>>>
>>>>
>>>> 3. new items may appear in the dropdown menus that currently are only
>>>> tools or context menu items
>>>>
>>>
>>> As mentioned, this is the primary goal of the reorganization. There are
>>> probably enough of these to result in general rearrangement. For example,
>>> a
>>> Tools menu will probably be added and Settings will not be a menu though
>>> the
>>> items will appear somewhere.
>>>
>>>
>>>>
>>>> 4. a new menu, the Window menu will be added
>>>> 5. another new menu, the Edit menu will be added
>>>>
>>>
>>> File and Edit will be the first two items; Window and Help will be the
>>> last
>>> two. Again this is a Mac standard thing.
>>>
>>>
>>>>
>>>> We are trying to be more explicit in the user guide,  by giving the
>>>> precise sequence of user actions, and all options for doing it (such as
>>>> menu, tool icon, context menu, shortcut). Also I think it is best if we
>>>> specify in the guide which toolbar a tool is on, so that if someone has
>>>> docked their toolbars in various places or turned some off, they know
>>>> where
>>>> to look (there are a lot of icons!). So this seems like a very
>>>> significant
>>>> shake-up to me, in terms of the effort required to update from a v0.11
>>>> compatible user guide to a v1.0 compatible user guide.
>>>>
>>>
>>> It is a significant shake-up. However, I think anything called 1.0 should
>>> have a somewhat more organized UI. I'm pushing for compliance with Apple
>>> menu guidelines so that a new user will find items in expected locations.
>>>
>>>
>>>>
>>>> I am searching for a way for us to move forward on some of the user
>>>> guide
>>>> updates without having to redo work after the GUI freeze- we just don't
>>>> have
>>>> the man/womanpower to do it.
>>>>
>>>> Here's a thought - if Tom can give us a GUI design, we can write the
>>>> user
>>>> guide to the design rather than the implementation. Then there is less
>>>> pressure on implementers to get things done quickly and less pressure on
>>>> document writers to do all the writing at the last minute. If there are
>>>> changes in the GUI design, we will know exactly where to go to modify
>>>> the
>>>> user guide, rather than having to make a full sweep through the guide.
>>>>
>>>
>>> I would like to make a menu proposal available for discussion next week.
>>> I
>>> don't know how long the discussion will last. Hopefully, half of it will
>>> be
>>> non-controversial and you can document that part first. After that, you
>>> can
>>> from time to time tell us we need to finalize one more piece.
>>>
>>> Tom
>>>
>>>
>>
>>
>>
>>
>
>
> --
> My e-mail delivery has been unreliable lately, so I am asking for
> return receipts from all my email messages.
> OK'ing the return receipt lets me know that my message was delivered.
> Thank you.
>
> Tara Athan
> Principal, Alternatives to Invasive Species
> tara_athan [AT] alt2is.com
> 707-485-1198
> PO Box 415
> Redwood Valley, CA 95470
>
>



-- 
Tim Sutton
QGIS Project Steering Committee Member - Release Manager
Visit http://qgis.org for a great open source GIS
Blog: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net