Hi well I don't see how you are going to view the source code before
downloading.  
If you are that concerned it is time to get a vm and run it first there.  
On the other points I agree.  A better example of where this is not being
done is the scripts for select text for example.  You are told there is an
update but you have no idea what bugs have been fixed etc.  I do not see
this as a big deal right now because we are still in beta but when the beta
is over people are going to want to know why they are updating.  This is
just standard paractus. I don't think it should be forced but I do think it
should be incur aged.  
-----Original Message-----
From: martin webster [mailto:[EMAIL PROTECTED] 
Sent: Saturday, September 06, 2008 1:38 PM
To: [email protected]
Subject: Re: Updated scripts really should include release notes!

Hi all.
I agree with daren, and I'll give you an example, the nudges script was a
perfect example, of a situation or script that may or nay not be used badly.
Know body was able to view the source code before download, and there are
some really good scripters on here.  I think another suggestion, is that
people should be able to view the sorce code before downloading, other than
the GwMicro staff.  It could save a lot of trouble in the long run.  Of
course, anybody downloading a script, where there is no documentation, is
mad, but it could quite easily happen, As an mechanical, engineer, we had to
document everything.  Even myself as a totally blind man, DOCUMENT! DOCUMENT
DOCUMENT.  well that's my two quids worth. 
Warm regards.
Martin Webster.



--- On Sat, 9/6/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:

> From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Subject: Re: Updated scripts really should include release notes!
> To: [email protected]
> Date: Saturday, September 6, 2008, 6:06 PM
> Thanks Darrell.
> 
> I did temporarily experiment with including them with the
> wepm, but I
> found it slightly pointless for my scripts when Script
> Central already
> offers a mechanism to have this information relayed at the
> point of
> update. Let's face it, us scripting folks do like a
> shortcut when we
> see it <grin>.
> 
> Darren
> 
> On 06/09/2008, Darrell Shandrow
> <[EMAIL PROTECTED]> wrote:
> > Hello Darren,
> >
> > No. The solution that has been implemented by most
> scripters is great. I'm
> > just advocating that all scripters do it. :-) Some
> high profile scripts
> > don't have release notes of any kind indicating
> the changes.
> >
> >
> > ----- Original Message -----
> > From: <[EMAIL PROTECTED]>
> > To: <[email protected]>
> > Sent: Saturday, September 06, 2008 8:08 AM
> > Subject: Re: Updated scripts really should include
> release notes!
> >
> >
> > Hi Darrell,
> >
> > Can you be a little more specific? If you go to the
> web page for most
> > scripts, the release notes for each incremental
> version are listed and
> > this page is also stripped of all formatting and shown
> in the edit box
> > that displays any new information when an update is
> detected. Are you
> > advocating inclusion of this same information staticly
> in the WEPM
> > file itself?
> >
> > Darren
> >
> > On 06/09/2008, Darrell Shandrow
> <[EMAIL PROTECTED]> wrote:
> >> Hello Everyone,
> >>
> >> I feel strongly that any script updated on Script
> Central ought to include
> >> release notes providing, at a bare minimum, a
> short summary of the changes
> >> made since the previous version was released.
> >>
> >> I don't necessarily want to update a piece of
> software, including a
> >> Window-Eyes script, simply because it is
> available. I want to have an idea
> >> what changes might be made to my Window-Eyes
> implementation, how those
> >> changes might impact my use of the application for
> which the script was
> >> written, and the new features available in the
> update. FWIW, this is just
> >> my
> >> two cents. :-)
> >>
> >> Regards,
> >>
> >>
> >> Darrell Shandrow - Accessibility Evangelist
> >> Information should be accessible to us without
> need of translation by
> >> another person.
> >> Blind Access Journal blog and podcast:
> http://www.blindaccessjournal.com
> >
> >


      

Reply via email to