M”te : Modeartorl”sa m”ten EchoID : R20_ Beskrivning : Huvudregler f”r regionala m”ten och moderatorl”sa m”ten Moderator : Moderatorl”st Nod : ML Nedanst†ende regler „r de regler som g„ller f”r moderatorl”sa m”ten. Denna regefil skickas d† best„llning av regler fr†n RuleFix gjorts f”r ett s†dant m”te. 2.0.1 M”tets namn M”tets namn ("ECHOID") skall inledas med 'R20_' och ha ett s† kort namn som m”jligt men att „mnet i m”jligaste m†n framg†r av namnet, t.ex. R20_PASCAL, R20_QBASIC eller R20_SOFT. 2.0.2 Teckenupps„ttning vid export N„r echomailmeddelanden som skapats inom det egna systemet exporteras f”r att skickas vidare f”r distribution via den regionala backbone-strukturen, †ligger det respektive sysop att se till att det sker med den teckenupps„ttning som „r best„md f”r respektive m”te. Teckenupps„ttning i svenska echom”ten skall vara fr†n och med datum 2000-08-01, den teckenupps„ttning som st”ds av CHRS-kludge med fallback till PC8 (CP 437/850). Med fallback till PC8 (CP 437/850) avses att om programvara inte st”der CHRS-kludge s† skall texten exporteras med teckenupps„ttningen PC8 (CP 437/850). PC8 avses h„r IBM:s 8-bitars version av ASCII, enligt CodePage 437. Om inte m”jlighet att anv„nda CP437 finns kan „ven CP850 f† anv„ndas. Undantag fr†n detta krav kan medges av REC i de fall det „r tekniskt befogat med ett s†dant undantag. Anv„ndning av s† kallade ramtecken avr†des best„mt, s†v„l som alla kosmetiska utsmyckningar i allm„nhet. T„nk p† att m†nga blinda och synskadade deltar i dessa m”ten, och inte kan tillgodog”ra sig grafik alls. 2.0.3 ™vrigt F”ljande regler skall till„mpas f”r alla svenska echom”ten om inte speciella sk„l f”religger. Om ett m”te „r avsett f”r en viss kategori av deltagare och inte „r ”ppet f”r alla, t.ex. ett betatestm”te f”r en programvara, s† kan regeln om allm„n tillg„nglighet s„ttas ur spel. En moderator ska inte inf”ra andra tekniska begr„nsningar „n vad som s„gs i till„mpliga tekniska dokument, t.ex inte best„mma om att sk. Hard CR inte f†r f”rekomma i slutet av rader eller att det m†ste g”ra det osv. Detta g„ller „ven ”vriga tekniska krav, t.ex. MSGID/REPLY kludges. S† l„nge det inte „r krav p† dessa enligt de tekniska standarddokument som g„ller s† ska man inte inf”ra regler om det i m”tet om det inte f”religger synnerligen starka sk„l f”r detta. T„nk p† att „ndam†let med m”tena „r att folk ska delta i dem och skriva inl„gg, inte att det ska ha s† m†nga regler som m”jligt. F”r mycket regler och begr„nsningar f†r bara till resultat att andra, nya, m”ten startas och deltagarna flyttar dit i st„llet. Varje regionalt distribuerat m”te skall ha en regelfil d„r moderatorns skyldighet „r att ha denna regelfil f”r h„mtning fr†n sitt system, samt/eller att skicka en kopia p† reglerna till REC[1] n„r de „ndras. Om moderatorn „r en anv„ndare eller ett pointsystem s† r„cker det med att regelfilen skickas till REC[1]. Regelfilen skall „ven inneh†lla en kort beskrivning av m”tes syfte och inriktning. Allra ”verst i regelfilen s† skall det „ven finnas ett huvud d„r uppgifter om m”tets ECHOID, moderatorns namn samt moderatorns Fidonetadress presenteras. Utformningen skall ha f”ljande format. M”te : M”tets namn EchoID : R20_EXEMPEL Moderator : Kalle Kula Nod : 2:20/2 Filnamnet skall alltid vara s† stor del av m”tesnamnet som m”jligt f”ljt av extension "RUL", t.ex. R20SFOSM.RUL eller SFOSM.RUL. Filen skall distribueras opackad. Namnet p† denna regelfil anges i den m”teslista som REC publicerar tillsammans med det nodnummer d„r filen finns f”r request. T„nk p† att reglerna skall vara s† 'intuitiva' som det „r m”jligt, dvs undvik en massa on”diga regler som bara ger till resultat att folk bryter mot dom i okunskap. Reglerna f”r det enskilda m”tet f†r inte bryta mot de standard- regler som finns f”r regionalt distribuerade m”ten enligt punkt 2.1. Reglerna skall regelbundet, minst var sj„tte vecka, postas i m”tet av moderatorn samt, om m”tet distribueras via backbone, skickas till REC, eller den som REC utsett, som fileattach enligt punkten 4.0 nedan. ([1] Eller den som REC utsett.) 2.1 Standardregler f”r svenska echom”ten ==================================== - M”tet „r avsett f”r diskussioner i „mnet ............ - Inl„gg utanf”r „mnet skall undvikas. Personliga p†hopp och ”ppen kritik p† andra m”tesdeltagare eller funktion„rer skall inte f”rekomma i m”tet, detta h„nvisas till netmail. - Avs„ndarens riktiga namn i klartext skall framg† av brevet, dvs pseudonymer ('handles)' „r normalt ej till†tna och inte heller olika till„gg till namnet, t.ex. 'Nils Adamsson /tajt' vilket kan f”rsv†ra personliga svar p† inl„ggen. Vidare skall avs„ndande systems adress framg†, enligt g„llande policys och tekniska dokument. - On”dig text oftast efter meddelandetexten, t.ex. uppr„knande av en massa alternativa adresser, fax- eller telefonnummer osv, streck-gubbar eller annan typ av 'reklam' i inl„ggen s†v„l som annan on”dig information som inte beh”vs f”r distributionen b”r i m”jligaste m†n undvikas eftersom det bara ”kar den m„ngd post som skall distribueras via dom olika kanalerna utan att det egentligen tillf”r n†got extra f”r m”tet eller ”vriga deltagare. - Anv„nd citat sparsamt, bara s† mycket som kr„vs f”r att f† l„saren att minnas sammanhanget. Att citera ett helt brev f”r att sedan l„gga till 'Jag h†ller helt med!' eller liknande „r att betrakta som ett brott mot reglerna. Upprepade s†dana brott (trots p†pekanden) kan komma att resultera i avst„ngning fr†n m”tet. - Spr†ket i m”tet skall vara svenska. Det „r till†tet att l„gga in kortare textfiler p† fr„mmande spr†k om de „r relevanta f”r den diskussion som f”rs. - Rent kommersiell annonsering av produkter/tj„nster f”r f”r- s„ljning „r generellt totalf”rbjuden med f† undantag. Privatpersoner kan annonsera i d„rf”r avsett echom”te, men f”rs„ljningen ska d† vara utan vinstsyfte. Vill du erbjuda en kommersiell f”rs„ljning, g”r d† det i netmail eller i d„rf”r avsett annonsm”te. Att uppmana till brott eller andra olagligheter „r ett allvarligt brott som normalt bestraffas genom avst„ngning, men „ven h†rdare p†f”ljder kan bli aktuella. - ™verl†t moderering till moderatorn. Har du synpunkter p† en persons uppf”rande, framf”r d† klagom†l via netmail antingen direkt till personen i fr†ga, eller till moderatorn som vidtar l„mpliga †tg„rder. Om synpunkterna g„ller moderatorn skall denne informeras via netmail. Om problemen kvarst†r kan fr†gan f”ras vidare till REC f”r avg”rande och eventuell †tg„rd. 2.2 Om m”tesdeltagaren bryter mot reglerna Om m”tesdeltagare bryter mot reglerna riskerar han att avst„ngas p† kortare eller l„ngre tid av moderatorn. Om det g„ller enstaka ”vertramp, skall det resultera i en varning fr†n moderatorn, via n„tbrev, men upprepade brott mot reglerna (trots varningar) kan till sist leda till avst„ngning fr†n m”tet. S†dant ”nskem†l om avst„ngning av deltagare skall alltid st„llas till NEC i det n„t d„r det felande systemet finns, med kopia till respektive sysop d„r inl„ggen skrivits fr†n. Om avst„ngningen g„ller systemets sysop, „r det vanligt att anse att hela noden „r avst„ngd fr†n m”tet, men avsteg fr†n detta kan beslutas av respektive moderator. Ett system som deltar i posthantering med en sk. administrativ adress (t.ex 201/0), kan inte avst„ngas fr†n ett m”te eftersom underliggande system d† drabbas. D„remot kan samma system avst„ngas p† dess egen nodadress. Trots att m”tet passerar genom systemet „r anv„ndarna (inklusive sysop) i ett s†dant fall inte till†tna att delta i m”tet. Proceduren kring avst„ngningar m.m. finns beskriven i EP1, och bl.a. kr„vs normalt att man varnat respektive person minst tre g†nger innan avst„ngningen verkst„lls samt att avst„ngningen alltid skall vara tidsbegr„nsad, i normalfallet i f”rsta hand tre m†nader. I s„rskilt grava fall kan avsteg fr†n detta g”ras och avst„ngningen verkst„llas omg†ende. Avst„ngning i preventivt syfte „r ej till†tet. Det vill s„ga om en person „r st”kig i ett m”te s† f†r denne inte st„ngas av i n†got annat m”te f”r att "f”rebygga" st”k i n†got annat m”te. Avst„ngningen skall via n„tbrev meddelas den avst„ngde, hans sysop samt respektive NEC. Sysop meddelar NEC n„r han sett till att den avst„ngde personen inte kan f† tillg†ng till m”tet. Om personen trots avst„ngningen forts„tter delta i m”tet, kan NEC via respektive Host besluta om avst„ngning av hela noden fr†n m”tet. 2.2.1 M”tesdeltagare och pointer Pointer j„mst„lls i detta sammanhang med deltagare/anv„ndare i allm„nhet i systemet (noden). Om en m”tesdeltagare bryter mot reglerna, s† skall klagom†len i form av varningar st„llas b†de till m”tesdeltagaren och till hans sysop (boss). Om problemen kvarst†r „r det respektive sysop som i f”rsta hand „r ansvarig f”r att se till att hans anv„ndare blir avst„ngd. Om detta inte sk”ts p† l„mpligt s„tt, kan den nod d„r anv„ndaren l„ser/h„mtar m”ten avst„ngas fr†n m”tet enligt ovan. Om sysop (boss) inte f†tt en kopia p† en varning f”r m”tes- deltagaren, s† „r varningen „nd† giltig om moderatorn kan uppvisa sin kopia till sysopen (boss) p† iv„gs„nt n„tbrev. Om m”jligheter finns f”r moderatorn b”r denne skicka varningar med en l„skvittens (CFM - Confirm Receipt Request), vilket g”r att mottagarens l„sprogram automatiskt s„nder ett kvittensbrev till moderatorn n„r mottagaren har l„st brevet. En annan s†dan bekr„ftelse f”r moderatorn „r att denne skickar varningar med mottagetkvittens (RRQ - Return receipt request) vilket g”r att mottagande systemets echomailprocessor skickar en kvittens till moderatorn n„r brevet anl„nt mottagarsystemet. Om moderatorn inte f†r ovan kvittenser inom n†got dygn s† b”r samma varning skickas ut till mottagarna †ter igen. Dessa kvittenser „r till f”r att undvika diskussioner om en varning framkommit till mottagaren alternativt mottagarens system eller ej. 2.3 Om klagom†l p† moderatorn finns Om m”tesdeltagare har klagom†l p† moderatorn eller synpunkter p† hans modererande skall detta framf”ra skriftligt till REC. Synpunkter p† m”tets moderator skall st„llas via n„tbrev i f”rsta hand till moderatorn, men om kritiken kvarst†r eller om man inte kan komma ”verens skall REC meddelas. En moderator som bed”ms uppenbarligen ol„mplig, eller som orsakar mycket klagom†l eller 'brus' kan genom beslut av REC bytas ut mot en annan person. Detta g„ller ocks† om ordinarie moderator inte l„ngre finns kvar i m”tet eller om han inte sk”ter sina †ligganden, t.ex. att regelbundet posta reglerna i m”tet, eller att inte uppdatera sina regler hos REC eller av REC utsedd person. S†dan avst„ngning skall ske f”rst efter f”rs”k gjorts att l”sa dom problem som finns. 2.4 Om m”tet orsakar skada eller obehag Eller om det bed”ms ol„mpligt att distribuera s† kan REC besluta om att stoppa distributionen av detta m”te via backbone/host/hub. Detta g„ller ocks† om moderatorn inte accepterar REC's beslut om byte av moderator eller liknande. Moderatorn „ger i s†dant fall beh†lla r„tten till m”tesnamnet om han s† ”nskar, och i f”rekommande fall sj„lv sk”ta distributionen av sitt m”te. 2.5 Moderatorl”sa m”ten F”r regionalt distribuerade m”ten s† skall det f”r varje enskilt m”te finnas en moderator. De m”ten som av en eller annan orsak blivit moderatorl”sa, skall REC se till att ny moderator tills„tts s† fort som m”jligt. 4.0 Krav p† backbone-distribuerat echom”te F”r att ett m”te skall f† distribueras via BACKBONE skall det anm„las av NEC i n„tet d„r moderatorn finns till REC och till ”vriga NEC, via avsett echom”te eller av REC utsett system. Vidare kr„vs normalt att minst ytterligare ett n„t anm„ler intresse f”r m”tet, via sin NEC. F”r att f”ra upp ett m”te p† regional niv† s† kr„vs det att m”tet f”rst finns uppsatt i det n„t som moderatorn befinner sig i samt att m”tet finns best„llningsbart f”r BACKBONE-noden (2:20/10) p† n„tniv† hos den Host som moderatorn befinner sig i. N„r det „r gjort s† skall NEC eller Host i n„tet se till att kontakt uppr„ttats med moderatorn i sj„lva m”tet. F”r att g”ra m”tet tillg„nligt f”r BACKBONE-noden s† „r det att f”redra att en s† kallad uppl„nklista skickas upp till BACKBONE-noden av NEC d„r det m”tet som skall s„ttas upp f”r regional distribution finns med. Detta f”rfarande underl„ttar och snabbar upp tillg„ngligheten av nya m”ten p† BACKBONE. F”r att m”tet sedan skall kvarst† som BACKBONE-m”te m†ste moderatorn regelbundet skicka g„llande m”tesregler eller p† angivet s„tt h”ra av sig till REC eller annan av denne utsedd person. Detta skall ske kvartalsvis. Uteblir dessa betraktas m”tet som avsomnat och riskerar att sluta distribueras via BACKBONE. Skulle det visa sig att m”tet „r aktivt men att n„mnda kontakt inte uppr„ttats kan REC tolka det som att m”tet saknar moderator och d† v„lja att utse ny i st„llet f”r att avf”ra det fr†n BACKBONE. 5.0 ™vriga upplysningar Fr†gor om tillg„nglighet p† m”ten st„lls i f”rsta hand till n„tets NEC, i andra hand till REC. ™nskem†l om nya m”ten som inte finns f”r distribution st„lls i f”rsta hand till n„tets NEC, i andra hand till REC. F”r den som har ”nskem†l om mycket smala m”ten eller m”ten som knappast kan intressera n†got st”rre antal noder eller l„sare i landet, men sj„lv inte kan importera dessa, h„nvisas till REC, som f”rmedlar kontakt med l„mplig import”r med vilken avtal om import av dessa m”ten kan g”ras. 6.0 Namn, adresser osv. REC SysOp 2:20/2 NEC200 SysOp 2:200/2 NEC201 SysOp 2:201/2 NEC203 SysOp 2:203/0 NEC204 SysOp 2:204/2 NEC205 SysOp 2:205/2 NEC206 SysOp 2:206/2 Rulefix, Central f”r regelfiler i region 20 (utsedd av REC). RuleFix H†kan Andersson 2:201/600 Backbonesystemet BACKBONE G”ran Eriksson 2:20/10 FTP-BACKBONE Jesper S”rensen 2:20/11