commenting on the draft and publishing final doc [was: Re: Group Note FPWD is done]

Hi Sharron,

AFAIR, this has been discussed at meetings and is in the minutes of  
some calls, but let me take this opportunity to summarize it roughly.

TOOL
----
We are using a tool called tracker [1]. Tracker interacts has a Web  
interface but also interacts with this mailing list and the #egov IRC  
channel. See previous pointer for help and commands.
This Group's instance is available at [2]. This tracker instance is  
fully public but only Group Members can edit, _all_ Group Members have  
editing rights.

COMPILATION OF COMMENTS
-----------------------
As the draft Note states, comments should be sent to this mailing  
list. The Group has encouraged one comment per email, although some  
commenters have submitted more detailed messages with several  
comments. We also appreciate suggested replacement text.

I've been taking care of splitting those, add them as issues to  
tracker [3] and link the email messages to them, but I'm a bit behind  
(will try to catch up asap). Any help is much appreciated.

Deadline for comments is April 26.

REVIEWING COMMENTS
------------------
Given that this is a Group Note (not a recommendation track document,  
i.e. a document expected to become a W3C Recommendation, a Web  
standard) and we were not expecting a huge number of comments, the  
Group decided a while ago to discuss every comment by email until the  
April 26 deadline as needed, then right after that start resolving  
what to do with every comment by email and also focus exclusively on  
achieving Group consensus about those on the April 29 Group call.

Some people have suggested to me that given this document will be used  
by governments and can have importance we should try to deal with  
comments as if it were a last call of a rec track one [4]. This means  
that it's not enough to agree on what to do with the comments among us  
but that we should try to find a solution that will also satisfy the  
commenter that could involve a more intense back and forth exchange.
Chairs will have a call on April 23 to review this but a decision by  
email could also come before then.

RESOLVING ISSUES
----------------
In any case, the Group should respond to all comments, trying to solve  
them in a way that satisfy the Group Members and commenters as much as  
possible. It may happen that in some cases not everybody will be  
satisfied, in that case the Group should record the objection and move  
forward.

_All_ issues must be closed before requesting publication of final  
document.

PUBLISHING FINAL DOCUMENT
-------------------------
Once discussed and resolved what to do with comments, changes must be  
integrated into the editor's draft [5], the doc must be compliant with  
W3C publication rules [6] (I usually take care of this part).
Some people have suggested we should find a good technical editor  
among us to give it a last pass before publication. Anybody reading  
with this background, time to do it and willing to help?

As we have discussed at previous Group call, we would like to have the  
final document published before May 21. Given the current publication  
schedule, we should resolve to request publication on the May 13 Group  
call and document would be likely published on May 19.


I hope this helps and if you review all the steps, you'll realize we  
have tight deadlines to deal with, but hope we'll meet them.

Cheers,
Jose.

ps: don't ever worry about posting often :)

[1] http://www.w3.org/2005/06/tracker/
[2] http://www.w3.org/2007/eGov/IG/track/
[3] http://www.w3.org/2007/eGov/IG/track/issues/open
[4] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
[5] http://www.w3.org/2007/eGov/IG/Group/docs/note
[6] http://www.w3.org/Guide/pubrules


--
Jose M. Alonso <josema@w3.org>    W3C/CTIC
eGovernment Lead                  http://www.w3.org/2007/eGov/


El 19/04/2009, a las 19:28, Sharron Rush escribió:
> Hello editors,
>
> Sorry to be posting so often, but am trying to get up to speed  
> within the group.
>
> I have a procedural question.  How does the IG log the comments that  
> we receive about the current Working Draft?  Do we maintain a  
> database and if so, do we note how each comment is resolved?  I have  
> been going back through the list to review comments that have been  
> received so far and wonder who responds and what the process is.   
> Perhaps it is on the wiki, and if so, I apologize for not being able  
> to find it.
>
> Many thanks for any guidance you can provide.
>
> Best,
> Sharron
>
>
>
> At 10:38 PM 4/16/2009, Hugh Barnes wrote:
>> Hi
>>
>> > -----Original Message-----
>> > From: public-egov-ig-request@w3.org
>> > [mailto:public-egov-ig-request@w3.org] On Behalf Of Jose M. Alonso
>> > Sent: Monday, 2 March 2009 8:09 PM
>> > To: eGov IG
>> > Subject: Group Note FPWD is done
>> >
>> > All,
>> >
>> > It has been a very intense weekend. Some of us, namely Kevin,
>> > John and
>> > me have been working until the very last minute on developing the
>> > final draft. We have worked on the document until yesterday night,
>> > then called it done.
>> >
>>
>> I have only recently caught up with the list backlog. This looks  
>> like the beginnings of an excellent resource. I agree, as some have  
>> suggested, that it might need to be slightly differently pitched to  
>> most W3C documents, in order to make the most impact on its target  
>> audience.
>>
>> > Final document is a snapshot of the current Editor's Draft
>> > [1] and we
>> > are requesting publication on March 10; comments will be welcomed
>> > until April 26.
>> >
>>
>> Something I'd like to see emphasised more is good practice around  
>> URIs (generally URLs in this context). They are given a few  
>> mentions, and those parts are really very well written (and bear  
>> repeating):
>>
>> "Transposed to namespaces and URIs this is quick sand on which to  
>> build an essential information infrastructure using the Web.</ 
>> p><p>To give an example of the consequences of this churn,  
>> governments have difficulty maintaining persistent URIs even to  
>> documents. Increasing volumes of official reports and documents are  
>> published on the Web alone making the long term availability of  
>> those resources an important issue. In this context 'link rot' is  
>> not just an inconvenience of the user, it undermines public  
>> accountability as documents cease to be available." [1]
>>
>> I would only add to this that inability to persist resources and  
>> manage URLs inhibits willingness to link between government  
>> agencies. This is a loss for users who wants a seamless government  
>> website experience and don't care which agency (or even government)  
>> hosts the information they seek. Government departments need to  
>> deep link more and with minimal risk consideration.
>>
>> A small working group within Queensland Government has produced  
>> some guidelines for minting and managing URLs because we believe  
>> they are pivotal to an effective web presence. The guidelines are  
>> accompanied by a business case and a solution specification. Though  
>> we have received some level of in-principle endorsement, I don't  
>> believe our mindshare is strong. We still struggle to convey the  
>> importance of the concepts. Important underpinning government-wide  
>> resources like legislation remain difficult to link to. (This also  
>> makes it near-impossible for us to populate the AGLS.mandate  
>> element.)
>>
>> So I suggest a (sub)section giving the topic more prominence. It  
>> would probably fit well within http://www.w3.org/2007/eGov/IG/Group/docs/note#OGD.how 
>> .
>>
>> The section should cover:
>> * that resources must be addressable canonically and persistently,  
>> including the appropriate and correct provision of fragment  
>> identifiers [2]
>> * the importance of trust in encouraging inward links and use of  
>> exposed data
>> * why URLs should be readable, logical, internally consistent, and  
>> truncatable (provides yet another interface to your data)
>> * managing and persisting URLs through HTTP rather than client-side  
>> techniques like JavaScript
>>
>> It might also cover:
>> * why HTTP redirects should only be made where the resource is  
>> essentially the same (I see a lot of redirects from a "deep"  
>> resource to a section entry page at its new location)
>> * why risk-averse indirect linking practices (e.g. interstitial  
>> pages, inplace warnings ("[external website]"), JavaScript warnings  
>> [3], spawning new windows, referrer URLs) are harmful and do little  
>> except inconvenience users
>>
>> I realise all that may be too much detail for an overview document.  
>> I cautiously offer to help with a draft. Only "cautiously" because  
>> I can't guarantee availability.
>>
>> Cheers
>>
>> Hugh Barnes
>> Resource Discovery Officer
>> Disability Services Queensland / Department of Communities
>> +61 7 324-74533
>>
>> ______
>> [1] http://www.w3.org/2007/eGov/IG/Group/docs/note#modalities
>> [2] The draft itself is exemplary in providing identifiers as  
>> anchor points (e.g. [1] itself), but unfortunately these only cover  
>> the extent of the section headings. I think this is a legacy W3C  
>> template remnant.
>> [3] for example, links out of http://www.dbcde.gov.au/communications_for_business/industry_development/digital_economy/future_directions_blog/topics/open_access 
>> , which is cited in the draft as [AU-OGD], and perhaps shouldn't be  
>> for this reason.
>>
>>
>>
>> "Queensland celebrates its 150th anniversary in 2009. Check out  
>> what's on today at www.q150.qld.gov.au."
>>
>> ********************************* DISCLAIMER  
>> *********************************
>> The information contained in the above e-mail message or messages  
>> (which includes any attachments) is confidential and may be legally  
>> privileged.  It is intended only for the use of the person or  
>> entity to which it is addressed.  If you are not the addressee any  
>> form of disclosure, copying, modification, distribution or any  
>> action taken or omitted in reliance on the information is  
>> unauthorised.  Opinions contained in the message(s) do not  
>> necessarily reflect the opinions of the Queensland Government and  
>> its authorities.  If you received this communication in error,  
>> please notify the sender immediately and delete it from your  
>> computer system network.
>>
>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.0.238 / Virus Database: 270.11.59/2063 - Release Date:  
>> 04/16/09 16:38:00

Received on Monday, 20 April 2009 09:27:31 UTC