Hello, I don't know very well SC but a list follows: A bug tracker could be implemented in SC. This should work as follows: 1- There's a bug tracking sistem in which one can just point the bug, how to reproduce it and some teste senarius. 2- An e-mail would be thrown to the autor plus the script list in a formated, well difined template automatically, with the informations from the bug created. 3- The autor or another member will take responsibility to fixing the bug. 4- As soon as it's fixed, it's also closed in the bug system and a entry saying something like "fixed bug xxxxx" would be generated in the script changelog inside SC. This way, documentation is generated and if one gets curious about what bug is that ... they can search for it in the bug tracking system. I think that there're even this kind of system already available to be implemented. An automated generated e-mail would also be sent to the scripts e-mail list.
An integrated featured system also could allow one to write wikis about given scripts, and the direct links should be available in the script section, making access to all documentation, written by the autor or other contributors, easy and centralized. This way, one could write the script and pass the keystrokes to a better writter and let they write the more detailed documentation, as an example. Marlon 2008/9/23, Aaron <[EMAIL PROTECTED]>: > > I'll chime in here as well, seeing as how SC is my baby. Posting what's > changed in a script update is really up to the script author, and is not > something that should be required. If you don't trust a script because of a > lack of update information, or are not comfortable installing a script > without knowing what's new, then don't use it. The open community model that > SC provides will control the success of a script. If enough people stop > using a script because they're not being told what it does, or what changes > have been made, then the script author may need to re-evaluate his or her > approach. > > Personally, I try to include at least a small snippet of all the changes I > make between versions. Not only does it create a constructive dialog with my > users about what I'm doing (especially for those who are not subscribed to > any GW email list), it helps me keep track of what I've done. This provides > me with a sort of development history. It's easy for me to review the > changes that have been made because I take the time to note them. I also > feel that the change history is part of script development. To me, a script > is not completed when the package is created, but instead is completed when > the package is made available to users. When that happens, I feel I should > tell them why I'm bothing them with an update in the first place. The time I > spend developing a script is no more important the the time someone takes to > download, install, and use my script. I try to keep that in mind when > providing updates, and so far, I think it's going well. > > Aaron > > -----Original Message----- > From: "J.J. Meddaugh" <[EMAIL PROTECTED]> > To: [email protected] > Date: 09/22/08 22:48 > Subject: Re: New Direct Text package > > I have to agree. Each author has their own way of expressing changes to a > script. > I'm considering going to an external changelog linked to on my scripts, for > example. > > ----- Original Message ----- > From: "Jared Wright" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, September 22, 2008 10:45 PM > Subject: Re: New Direct Text package > > >> Darrell Shandrow wrote: >> "I'd go so far as to say that a change log or release notes ought to, >> somehow, be required by GW Micro in order to post on SC..." >> Somehow I think this would only drive people away from SC and thus >> neutralize its SC's usefulness as a whole. >> >> >> JW >> > > -- When you say "I wrote a program that crashed Windows," people just stare at you blankly and say "Hey, I got those with the system, for free." Linus Torvalds
