= Сообщение: 73 из 7128 ======================================== FTSC_PUBLIC = От : mark lewis 1:3634/12.71 22 Oct 13 20:31:52 Кому : Nick Andre 22 Oct 13 20:31:52 Тема : FTSC Nominations FGHI : area://FTSC_PUBLIC?msgid=1:3634/12.71+26714f11 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://FTSC_PUBLIC?msgid=2:292/854+b7047551 ============================================================================== On Tue, 22 Oct 2013, Nick Andre wrote to All:
NA> On 21 Oct 13 20:17:23, Mark Lewis said the following to Ross NA> Cassell:
ML> On Mon, 21 Oct 2013, Ross Cassell wrote to Ward Dossche: ML> ML> RC> Do we need a FTSC? ML> ML> yes... for several reasons... ML> ML> 1. to ensure that software conforms to the standards and proposals ML> they support.
NA> Wrong. The FTSC's job is not to babysit products that do not NA> conform to published standards.
no one said anything about babysitting, nick...
ML> proposals they choose to support in their software.
NA> Very rare. The published standards are fairly straightforward.
really? then why does one have to test implementations against other software to see how it/they work so they can be duplicated... even if those implementations are not to the spec being followed? this does introduce confusion and misunderstanding... eg: some folks believing that the husky method of naming all bundles with different names and the same xx0 extension instead of using the same base name and incrementing the xx0 extension to xx1-Z...
ML> 3. to assign product ID codes to new software being developed.
NA> Extremely rare.
i'm aware of at least two products which should have a PID assigned so that other software that processes based on the PID in the PKT don't screw things up... this situation was brought up recently in a developing package's support area... the cause, as indicated by the reporting party, was that the PID in the PKT indicated one package but this was another and the PKT format was not that which was expected... that points to two problems... the main one being some package expecting to process mail based on the package that supposedly created the PKT rather than analyzing the PKT to determine which type it is and then processing it...
ML> at least those three in addition to the updating and review of existing ML> standards and proposals as well raising proposals to standards...
NA> And how often does that happen again?
there are documents, now, that are "expired" because a FTSC has not reviewed them and updated them or at least altered their expiration date... this type of stuff was set up by the second FTSC in an effort to keep the FTSC alive and having something to do to indicate activity...
NA> Everyone else reading - I was once an elected FTSC member, and the NA> behavior of a few elected FTSC participants was far from their NA> elected purpose of managing existing technical documents. Ongoing NA> rants and raves about the most trivial topics one can shake a NA> stick at. Very negative tones from those few members who were NA> elected on their "technical contributions".
and no other parties are guilty as well? it takes two to tango, ya know...
NA> I will reiterate what Michiel has stated - Anyone looking to join NA> the FTSC in hopes of resurrecting our hobbby into the next NA> Facebook should think twice.
it is not about ressurection... it is about doing the job of the FTSC and to actively assist when asked or to offer assistance when problems are seen...
NA> My opinion is to cut down the FTSC to one or two individuals. Thats NA> all thats needed. And set clear term-limits. No exceptions. Make NA> the private FTSC echo public for total transparancy so those who NA> (blindly) vote in a candidate can see clearly how that candicate NA> conducts themself and "does their job".
...
NA> Stop making the FTSC sound like its curing cancer...