【RFC-140】限制用户RFC发表数量，防止RFC被滥用
理由:
最近这个月RFC有点过多了，是过去三个月的和，且大量的rfc有重复嫌疑，都没有通过，被转水。
同时每天一上线就是大量的通知@发到头上，虽然可以关掉提示，但这无疑是一种信息污染……还有的人多次在同一帖子下全部@管理员，占用了很多时间，严重影响管理员使用品葱的其他功能——比如写文章，发提问等
刚才还看到@懦夫斯基 的这个帖子，https://pincong.rocks/article/10745
管理员真的很难做啊！
改动方案：
1.限制每个账号每月RFC提出数量，就像一般现实中议会运行那样。一人一月最多一次，确保了RFC的质量再发，免得有的用户第一个RFC达不成目标就提下一个。超量的RFC可以无理由删除。
2.限制单一帖子下@管理员次数，在同一帖子下只允许@全体管理员一次，从@第二次开始，管理员可以删除。
3.排期制度，在之前的RFC结束前，可以发新的pre-RFC，可以讨论，但不允许@全体管理员。
4.pre-RFC需要5名管理员联署才能进入正式RFC排期，五名管理员点赞主楼即可，同时RFC提出者需要在主楼记录联署管理员名单。RFC没投票截止前，如有新开的RFC，管理员可以主动把该RFC锁定，直到旧的RFC投票结束后可以解锁。
本RFC 投票暂定到EST 12/21截止
最近这个月RFC有点过多了，是过去三个月的和，且大量的rfc有重复嫌疑，都没有通过，被转水。
同时每天一上线就是大量的通知@发到头上，虽然可以关掉提示，但这无疑是一种信息污染……还有的人多次在同一帖子下全部@管理员，占用了很多时间，严重影响管理员使用品葱的其他功能——比如写文章，发提问等
刚才还看到@懦夫斯基 的这个帖子，https://pincong.rocks/article/10745
管理员真的很难做啊！
改动方案：
1.限制每个账号每月RFC提出数量，就像一般现实中议会运行那样。一人一月最多一次，确保了RFC的质量再发，免得有的用户第一个RFC达不成目标就提下一个。超量的RFC可以无理由删除。
2.限制单一帖子下@管理员次数，在同一帖子下只允许@全体管理员一次，从@第二次开始，管理员可以删除。
3.排期制度，在之前的RFC结束前，可以发新的pre-RFC，可以讨论，但不允许@全体管理员。
4.pre-RFC需要5名管理员联署才能进入正式RFC排期，五名管理员点赞主楼即可，同时RFC提出者需要在主楼记录联署管理员名单。RFC没投票截止前，如有新开的RFC，管理员可以主动把该RFC锁定，直到旧的RFC投票结束后可以解锁。
本RFC 投票暂定到EST 12/21截止
82 个评论
UCCMaoist
观察
同意，建议门槛再高一点，2个月一次，1周最多审议4个RFC。
虽然不想用这个功能但还是用了：
@一只鹿兒 @苏维埃督战队 @admin
@陈美丽 @InspectorBen @懦夫斯基 @荣誉非国民 @killreddragon
@利维坦 @FreedomAsia @红冬里的青鱼 @anonymousLiu @waliesi
@guibuhai @Tashkent @en010272 @viewer @rtgzddgh
@tony231 @陪你去看毛新宇 @中国网警巡查执法 @令狐冲 @陈士杰
@姨湃湖岩 @chobe @1901zxc已停用 @小钙 @经略
@白頭翁 @Alleria @balibali @炎黄子葱
@vvgvv1 @邓丽君 @第三新索多玛 @巴巴罗萨 @币圈奇葩8964
@组组组组 @疯狂习近平 @由比滨结衣 @還是小學生 @winkcat
@时代革命 @Shekzara @magrabee @Pepperoni @小汪酱
@橘希实香 @若名用户 @Merlin @Hunter @清水照子
@月社妃 @社会煮役铁拳 @fb_china_today @niubility
@jerry168 @HelicopterZ @LuvDDDD @pc6650 @Pracseeuvn
@带带大师兄 @不存在 @仲长若谷 @Arthur_Fleck @ikuyui
@马拉糕 @Ambulance @reppep @VR46
@2样2simple @nmff @韭菜地里一根葱 @Organsland @arashi8964
@江上风流胜习家 @維尼學跳舞 @黑杰克 @正義終將戰勝歸來 @眼镜娘阿锅
@吳樂天 @做个清醒的人 @民主信仰者 @守法刁民
@yogafire @逆流而上的鱼 @末代皇帝习禁评 @咸鱼老李 @幹乾干停用
@rgjdwte @Gogh9836 @拉法兒 @Meltdown @silaoye
@自由党人 @米路庫 @润之的忏悔 @HenkGao @中华合众国
@路过一下 @唵嘛呢叭咪吽 @且翻且珍惜 @一勺3分糖 @韭菜地里一支韭
@Android @zhengyi @freedomisours @向往光明的韭菜
@Natasha @hiyoall @碴条 @Geena @书记
@鸡鸡 @大差不差 @Nakayama @Tseyu
@burleigh @葱侠 @小狗包帝 @EPSON @安娜
@Benzene @lelouchgreat @匮名用户 @Sulaiman_Gu @Kou_Takumin
@我死了 @Nihilistra @kcyx2184 @mtw1994ja @Dualeagles
@勃列日涅夫 @美游的哥哥是妹控 @grantyang @品姜 @d444c
@剑心 @Philadelphia @spark808 @广场青年 @anonym
@孙金香 @avatar @Hermione @立紗Lisa
@awuwu @trtrtr2 @专杀恶警不服就干 @普习金 @人性的曙光
@MyWolf @文不能測字 @bdcbdc @RandomID_1 @救救孩子
@jsglsjh @小哼哼lulu @荊棘之心 @asd123088 @ratdotlight
@存在者09 @说我想说的 @谁愿意去开坦克呢 @bicteoo
@marbling @feefee @畅所欲言 @江泽民 @myfuture
@xxvonch @念诗之王习近平 @Smtsmt @梅菲斯特 @No_pains
@Fredrick @包宗馅帝刁庆丰 @Keii @Matthew @harmonize
@丁丁在美洲 @流氓匪首停用 @meta_chaos @赫胥黎 @decemeber19
@molecular @huma @停用ing @SolIII觀測站 @孙小果
@aggie @HaugenOyoung @伟大元首习特勒 @miule236236 @Tetra
@匿名反賊芽孢君 @地球人 @Hokkien @扬子江 @Noone
@一毛不拔 @最大公约数 @Applepie @theflash @Haloawold
@罗马相册 @Hker @圣锹游侠 @23mofang @乔治奥威尔
@id1984 @containccp @NNNN @zfedit001 @庆丰包子的梦帝
@Yeahwhatever @rockman @若狭悠里 @Wolfychan @调戏萌新专用号
@张树人 @路人 @ThinkTank64 @youtuberr
@羊城暗夜 @国服我服不服 @皇天擊殺甴曱平
@江沢民
@一只鹿兒 @苏维埃督战队 @admin
@陈美丽 @InspectorBen @懦夫斯基 @荣誉非国民 @killreddragon
@利维坦 @FreedomAsia @红冬里的青鱼 @anonymousLiu @waliesi
@guibuhai @Tashkent @en010272 @viewer @rtgzddgh
@tony231 @陪你去看毛新宇 @中国网警巡查执法 @令狐冲 @陈士杰
@姨湃湖岩 @chobe @1901zxc已停用 @小钙 @经略
@白頭翁 @Alleria @balibali @炎黄子葱
@vvgvv1 @邓丽君 @第三新索多玛 @巴巴罗萨 @币圈奇葩8964
@组组组组 @疯狂习近平 @由比滨结衣 @還是小學生 @winkcat
@时代革命 @Shekzara @magrabee @Pepperoni @小汪酱
@橘希实香 @若名用户 @Merlin @Hunter @清水照子
@月社妃 @社会煮役铁拳 @fb_china_today @niubility
@jerry168 @HelicopterZ @LuvDDDD @pc6650 @Pracseeuvn
@带带大师兄 @不存在 @仲长若谷 @Arthur_Fleck @ikuyui
@马拉糕 @Ambulance @reppep @VR46
@2样2simple @nmff @韭菜地里一根葱 @Organsland @arashi8964
@江上风流胜习家 @維尼學跳舞 @黑杰克 @正義終將戰勝歸來 @眼镜娘阿锅
@吳樂天 @做个清醒的人 @民主信仰者 @守法刁民
@yogafire @逆流而上的鱼 @末代皇帝习禁评 @咸鱼老李 @幹乾干停用
@rgjdwte @Gogh9836 @拉法兒 @Meltdown @silaoye
@自由党人 @米路庫 @润之的忏悔 @HenkGao @中华合众国
@路过一下 @唵嘛呢叭咪吽 @且翻且珍惜 @一勺3分糖 @韭菜地里一支韭
@Android @zhengyi @freedomisours @向往光明的韭菜
@Natasha @hiyoall @碴条 @Geena @书记
@鸡鸡 @大差不差 @Nakayama @Tseyu
@burleigh @葱侠 @小狗包帝 @EPSON @安娜
@Benzene @lelouchgreat @匮名用户 @Sulaiman_Gu @Kou_Takumin
@我死了 @Nihilistra @kcyx2184 @mtw1994ja @Dualeagles
@勃列日涅夫 @美游的哥哥是妹控 @grantyang @品姜 @d444c
@剑心 @Philadelphia @spark808 @广场青年 @anonym
@孙金香 @avatar @Hermione @立紗Lisa
@awuwu @trtrtr2 @专杀恶警不服就干 @普习金 @人性的曙光
@MyWolf @文不能測字 @bdcbdc @RandomID_1 @救救孩子
@jsglsjh @小哼哼lulu @荊棘之心 @asd123088 @ratdotlight
@存在者09 @说我想说的 @谁愿意去开坦克呢 @bicteoo
@marbling @feefee @畅所欲言 @江泽民 @myfuture
@xxvonch @念诗之王习近平 @Smtsmt @梅菲斯特 @No_pains
@Fredrick @包宗馅帝刁庆丰 @Keii @Matthew @harmonize
@丁丁在美洲 @流氓匪首停用 @meta_chaos @赫胥黎 @decemeber19
@molecular @huma @停用ing @SolIII觀測站 @孙小果
@aggie @HaugenOyoung @伟大元首习特勒 @miule236236 @Tetra
@匿名反賊芽孢君 @地球人 @Hokkien @扬子江 @Noone
@一毛不拔 @最大公约数 @Applepie @theflash @Haloawold
@罗马相册 @Hker @圣锹游侠 @23mofang @乔治奥威尔
@id1984 @containccp @NNNN @zfedit001 @庆丰包子的梦帝
@Yeahwhatever @rockman @若狭悠里 @Wolfychan @调戏萌新专用号
@张树人 @路人 @ThinkTank64 @youtuberr
@羊城暗夜 @国服我服不服 @皇天擊殺甴曱平
@江沢民
同意，窝佬已经被@烦了，甚至想开贴求别@
窝佬认为更合适的方式是，要求RFC提出时即有3/5个以上的管理员联署，才可以发表。
因为RFC发出后肯定会@挺多人的。不如干脆把成本进一步抬高。
实际上是把联络的成本转移给一开始发出RFC的管理员
因为RFC发出后肯定会@挺多人的。不如干脆把成本进一步抬高。
赞同1与2，限制RFC数量，恢复pre-RFC草案机制，pre-RFC期间不可使用集体召唤功能。
在1与2通过的基础上，不赞同3.
如何防止恶意占领排期？假设我们复现一下十月的大吵架，我如果怀有恶意，或者单纯情绪上头，可以抢先抛出一个有争议的RFC，获得几个人支持，占领排期。网络世界拖上一个星期，所有事情都要归于虚无了。
同时还要考虑到，不是所有人都几乎每天上品葱，有些管理员可能会每隔几天，花一整块时间在品葱上进行交流。排期对持有此类使用习惯的管理员十分不利。
如果1与2通过，同一时期的RFC不会很多，没必要强制排期。
在1与2通过的基础上，不赞同3.
3.根据《罗伯特议事规则》建立排期制度，在之前的RFC结束前，可以发新的RFC，但自动进入锁定状态，上一RFC结束后，按照顺序解除其锁定状态并进行讨论。
如何防止恶意占领排期？假设我们复现一下十月的大吵架，我如果怀有恶意，或者单纯情绪上头，可以抢先抛出一个有争议的RFC，获得几个人支持，占领排期。网络世界拖上一个星期，所有事情都要归于虚无了。
同时还要考虑到，不是所有人都几乎每天上品葱，有些管理员可能会每隔几天，花一整块时间在品葱上进行交流。排期对持有此类使用习惯的管理员十分不利。
如果1与2通过，同一时期的RFC不会很多，没必要强制排期。
赞同1与2，限制RFC数量，恢复pre-RFC草案机制，pre-RFC期间不可使用集体召唤功能。在1...
一个月只允许发一个RFC啊，恶意占领排期也没用，发第二个就会被删，也很难占领吧？
一个月只允许发一个RFC啊，恶意占领排期也没用，发第二个就会被删，也很难占领吧？
如果用户抱团，轮流发RFC，持续无意义的争论，就可以造成故意延宕。如果有这种情况，到时候还是要大家临时同意忽略/跳过这种RFC，排期也就作废了。美国议会filibuster问题就是类似的故意延宕。
如果用户抱团，轮流发RFC，持续无意义的争论，就可以造成故意延宕。如果有这种情况，到时候还是要大家临...
要求三名/五名管理员的联署才可发RFC，进一步提高故意阻塞的成本即可。
1.弃票
2非常支持，这功能必须开发啊，一个一个艾特元老们，真的很累的：（
3.弃票
2非常支持，这功能必须开发啊，一个一个艾特元老们，真的很累的：（
3.弃票
虽然不想用这个功能但还是用了： ousLiu ...
一个也没艾特上。
要求三名/五名管理员的联署才可发RFC，进一步提高故意阻塞的成本即可。
三五名联署，岂不是更有利于小团体了。如果一个制度下，抱团可以增强话语权，那么必然会造成抱团的结果。管理员的独立性需要维护。
不认同1和2条。作为论坛管理员，对RFC提案进行审理并发表意见，是管理员的义务之一。最近的确有比较多RFC产生，但提出的问题，都是论坛长期以来存在的一些弊病。
我认为，现在RFC的频率，远未达到让人无法忍受的程度。真正的问题是，品葱已经有250名管理员，但平时会积极参与到法案讨论中的，大概只有20人不到。如果大多数管理员都整天高谈阔论，却不关心实实在在影响到每一位用户的政策，只是在议案影响到自己利益的时候跑出来反对一下，实在是说不过去。论坛的民主化建设，又从何谈起呢？所以，对于任何限制提案的做法，无法苟同。
我对第三条的思想比较认同，但认为实际操作手段有待商榷。品葱目前的问题，是论坛建设这一方面，需要有专门的一群管理员着手去做。例如，RFC的审理、表决、通过后的整理，对制度建设的观察与研究，都是非常实际的工作。
我建议应当设立一个比较松散的“制度建设委员会”，初期采用报名制，后期采用邀请制，汇集一些对品葱制度建设有热情的葱油们，专注于这方面的一些比较具体的工作。
如果有任何RFC提出，需要先以pre-RFC的形式通过委员会的初审，获得3人支持以后，在进一步完善形成初稿的情况下，再以正式RFC的形式进行表决。这样的话，既保证了议案的质量，也可以让议案的发起者有一个公开的方式寻求支持和建议。委员会成员及发起人负责提案的投票跟进，以及通过后加入RFC-Tracker，修订习惯法等后续工作。
在平时，这个委员会的成员也可以对论坛未来的走向，和下一步政策进行讨论。
总而言之，我认同这个RFC的思想，但不认同实际操作的方式，建议先作修改。
我认为，现在RFC的频率，远未达到让人无法忍受的程度。真正的问题是，品葱已经有250名管理员，但平时会积极参与到法案讨论中的，大概只有20人不到。如果大多数管理员都整天高谈阔论，却不关心实实在在影响到每一位用户的政策，只是在议案影响到自己利益的时候跑出来反对一下，实在是说不过去。论坛的民主化建设，又从何谈起呢？所以，对于任何限制提案的做法，无法苟同。
我对第三条的思想比较认同，但认为实际操作手段有待商榷。品葱目前的问题，是论坛建设这一方面，需要有专门的一群管理员着手去做。例如，RFC的审理、表决、通过后的整理，对制度建设的观察与研究，都是非常实际的工作。
我建议应当设立一个比较松散的“制度建设委员会”，初期采用报名制，后期采用邀请制，汇集一些对品葱制度建设有热情的葱油们，专注于这方面的一些比较具体的工作。
如果有任何RFC提出，需要先以pre-RFC的形式通过委员会的初审，获得3人支持以后，在进一步完善形成初稿的情况下，再以正式RFC的形式进行表决。这样的话，既保证了议案的质量，也可以让议案的发起者有一个公开的方式寻求支持和建议。委员会成员及发起人负责提案的投票跟进，以及通过后加入RFC-Tracker，修订习惯法等后续工作。
在平时，这个委员会的成员也可以对论坛未来的走向，和下一步政策进行讨论。
总而言之，我认同这个RFC的思想，但不认同实际操作的方式，建议先作修改。
三五名联署，岂不是更有利于小团体了。如果一个制度下，抱团可以增强话语权，那么必然会造成抱团的结果。管...
请勿野蛮碰瓷。
1.五名联署，意味着如果只有无人支持的五个管理员，只能阻塞一周的RFC发言机会。
如果有无人支持的十个，也只能阻塞1/2的发言时间。你葱现在的机制其实也根本挡不住十个铁了心兴风作浪的管理员。
2.当时有管理员试图落实没有通过决议的【不可描述网站部分用户的不可描述化】政策。你也没有出言阻止。我就不说你抱团/利益相关了。你并不是超然物外的。
3.站长之前确认过，
你葱本来也不需要提前规划好一切。先有人恶意利用了再说行吧？RFC的所有发表都是受监督的，显著的恶意操控有什么看不出的？不要画鬼，qqqxx。
不要像是之前不停说抱团刷赞的隐患，某管理员的数据一拿出来，根本没有什么抱团刷赞的显著特征。
4.你葱没有RFC按默契来行事的时候也没垮台了。看看RFCTracker就知道了。请不要无限抬高本RFC的风险。
请勿野蛮碰瓷。1.五名联署，意味着如果只有无人支持的五个管理员，只能阻塞一周的RFC发言机会。如果有...
不是针对你，请你不要太着急对号入座。提出这个可能性，是因为这几天有个帖子提出“建立党团”的建议，下方有一些附和的声音，愿意形成团体。
不是针对你，请你不要太着急对号入座。提出这个可能性，是因为这几天有个帖子提出“建立党团”的建议，下方...
我觉得可以搞一个公开委员会来处理RFC质量较低和排期的问题，没必要作数量上的硬性限制。恢复pre-RFC有必要。
主楼提出的问题是大量at有些被滥用，只针对这个问题，其实我觉得只要实现主楼的第二条，就可以迅速解决了。
建立新机制可能需要更多的论证，避免引入更多问题，推动起来会比较缓慢。
建立新机制可能需要更多的论证，避免引入更多问题，推动起来会比较缓慢。
不认同1和2条。作为论坛管理员，对RFC提案进行审理并发表意见，是管理员的义务之一。最近的确有比较多...
这一个月RFC差不多20条了，已经是之前快三个月之和了，而且大量的也被转水并且没有通过，说明这这几期RFC的质量确实有一定的问题。
主楼提出的问题是大量at有些被滥用，只针对这个问题，其实我觉得只要实现主楼的第二条，就可以迅速解决了...
第二个问题已经讲很久了，其实是技术性问题，能开发出自动@的系统就好了。
或者就像处理举报那样，让部分管理员和有能力的用户自愿报名去做提案的预审工作，不要一下子就@所有人。
但说实话我觉得如果做管理员就要有被不停@的觉悟，不然干脆就不要做，让有能力和热情的来。（快点把退出机制确认下来吧）
但说实话我觉得如果做管理员就要有被不停@的觉悟，不然干脆就不要做，让有能力和热情的来。
你葱本来目标就是让多数非全职管理员都可以对网站产生影响。而非少数精力充沛者主导。
你葱本来目标就是让多数非全职管理员都可以对网站产生影响。而非少数精力充沛者主导。
这不矛盾嘛，所以精力充沛的可以去审查举报和提RFC。但非全职的管理员，也有义务对RFC做审理和回复。否则相当于搞一个投票大部分人都弃权，就算通过也没办法体现民意。
第二个问题已经讲很久了，其实是技术性问题，能开发出自动@的系统就好了。或者就像处理举报那样，让部分管...
“让有能力和热情的来。”这个有点加戏，九头鸟也有热情你要让他当管理员嘛？
话说你和trtrtr2两位朋友发的都有点多，而且很多内容实在是重复，本来我是完全没想到这条的，现在已经跟大约达到支字头巅峰的@大家1/4程度了，量实在有点过多了。
这不矛盾嘛，所以精力充沛的可以去审查举报和提RFC。但非全职的管理员，也有义务对RFC做审理和回复。...
限制RFC提出速度可以实际上可以让玩网少的用户有更多权限。
而且从本楼来看，不少管理员觉得你葱现在没有大量亟待改变的东西。
“让有能力和热情的来。”这个有点加戏，九头鸟也有热情你要让他当管理员嘛？话说你和trtrtr2两位朋...
我知道trtr发得比我多不少，所以也没提他名字，不想变成对某一位用户的讨论嘛。但现在状况是，RFC提了以后，基本上都是靠提RFC的人自己去想，自己去推，大部分人都看戏，缺乏一个事先的协调和事后的跟进机制，这点你不否认吧？
所以要解决问题的根本措施还是让一部分愿意花这个时间和精力的用户去做法案初审，也要肯定制订RFC的工作和立法一样，不是所有人都愿意做且有能力做的。减少@的措施只是治标不治本，其实加一个@全体管理员的功能其它RFC里面也早就提了。
包括你这个RFC，比较合适的做法也是先发一个pre-RFC讨论收集意见，在有共识的基础上继续作推动。
我知道trtr发得比我多不少，所以也没提他名字，不想变成对某一位用户的讨论嘛。但现在状况是，RFC提...
联署的意义是让想推动某个RFC的用户，在发帖之前就要靠自己去联络支持者，而且支持者要愿意付出每月一次的提议机会来支持。这一阶段不会进入大部分用户的视野。
潜在支持者少的RFC会直接在这一轮被过滤掉，反正支持者不足也不用提了。
这样大部分用户，看到某个新RFC主题帖时，就是至少有不少管理员已经很重视某项提议了。而不是任何一个RFC，你葱管理员理论上都该看，实际上极少愿意去看。
再限制频率以后，五个人级别的小团体（如果你葱真存在这种小团体，那已经非常大了），一月只能发动一次RFC。潜在风险并不大。
联署的意义是让想推动某个RFC的用户，在发帖之前就要靠自己去联络支持者，而且支持者要愿意付出每月一次...
联署我觉得想法不错，但技术上是个大坑.....你确定admin有精力再搞这么一个玩意么.....不然难道用人工计算谁用了提议机会谁没用吗.....
实际操作起来....我觉得可能更复杂。而且，如果有人违反规则，谁来监察这个频率是否超出了？
不过这问题挺有意思的，仔细想下去牵涉到立法和行政之间的操作。
联署我觉得想法不错，但技术上是个大坑.....你确定admin有精力再搞这么一个玩意么.....不然...
让发帖人自己列出来有谁愿意支持他，并且给出授权的发言链接。
支持者：
AD3，链接
BE4，链接
CF5，链接
这种格式就够了。不必一定得改代码。
不规范格式/虚假联署的惩罚给发帖者承担。（扣威望/吊销管理员权限）
我知道trtr发得比我多不少，所以也没提他名字，不想变成对某一位用户的讨论嘛。但现在状况是，RFC提...
要不就设立一个pre-RFC专区，新RFC必须先在pre-RFC里讨论完毕通过联署然后再摆在RFC专区内部。pre的部分就别@全体管理员了，几个人先把内容具体讨论好联署完毕，然后再推到RFC区。
但限量和排期是必须的，目前来看我觉得不限量的话还是治标不治本。
排期可以确保你们有联署，有共识的pre-rfc优先审理，限量的话其实各国议会都有类似的规则，我记得你一直希望很多制度仿照现实中的方案吧？现在这个就是一种啊。
一个也没艾特上。
正如我所说的我没用过这项功能，因此不熟悉，你要有时间不如帮我@下，我回头把上面的@删了XD
要不就设立一个pre-RFC专区，新RFC必须先在pre-RFC里讨论完毕通过联署然后再摆在RFC专...
pre-RFC是可以的，我现在自己的提案都会先pre-RFC收集意见，我觉得很有必要。而且在这个基础上我更倾向于有一群热心用户自愿报名去做pre-RFC议案的审核与讨论，这样发pre-RFC的时候直接@他们就行，不用去@整个管理员团队。
所以我觉得先把pre-RFC恢复，建立管理员联署机制，并且建立一个愿意去看pre-RFC提建议的用户名单就行了（貌似20声望以上用户就可以提RFC，所以这个名单不一定必须全为管理员）。
限量和排期我觉得理论上可行，实际上必然要有配套措施，比如说议会或者论坛系统这样的机制来执行，一定要有人来控制议事流程，否则监察起来很有难度。但品葱议会到现在就开过一两次会再无下文，我觉得指望这个不大靠谱。
不过既然有联署机制，我觉得限量排期做不做也无所谓了，靠内部协调就行。
最后多说一句，虽然无法强制，但我还是希望有投票权的管理员朋友们多用好手中的民主权利，多关心RFC方面的事务。参与讨论和表决是民主决策过程中必不可少的环节。
再次引用 @Publius 这位葱油的一段话：
https://pincong.rocks/question/12855
最後，可能會有蔥友會疑問，我們這樣的討論有意義嗎？
有意義，而且這是我們的責任。
品蔥是華文世界裡面一個獨特的自由討論時政（免於政府強制和五毛干擾）的「法外之地」。來到這裡的人是分佈於世界五湖四海的華人，有剛出國留學的，有「肉翻」不久的，有長年生活在外國的，有在台灣多年親歷華人民主的，有在香港戰鬥在最前線的，也有在大陸能找到片刻寧靜與安慰的。我們擁有億萬同胞都不具備的條件，如果我們不去認真討論深究民主理論與實踐，不是一種不公的話，那什麼是不公呢？
正如我所说的我没用过这项功能，因此不熟悉，你要有时间不如帮我@下，我回头把上面的@删了XD
我只会手打艾特 他们一下艾特一大串我也不知道怎么做到的
第二个问题已经讲很久了，其实是技术性问题，能开发出自动@的系统就好了。或者就像处理举报那样，让部分管...
我也认为管理员拥有权限与接受通知的义务是绑定的，此前在水区发布休假楼，更多是为了防止辱骂等攻击管理员的垃圾信息，保护管理员账号背后的真人。
不过目前大家似乎激情澎湃，没人打算休假……看一看接下来几个星期，网军攻击管理员的现象是否会持续，如果真的持续，可能要考虑提议建立强制休假制度了。跑题了，抱歉。
已隐藏
我也认为管理员拥有权限与接受通知的义务是绑定的，此前在水区发布休假楼，更多是为了防止辱骂等攻击管理员...
攻击管理，当然就必须挨管理铁拳啊，我是黑管（警），手握警棍，暴力执法，我还怕五毛不成¿
1.限制每个账号每月RFC提出数量，就像一般现实中议会运行那样。一人一月最多一次，确保了RFC的质量再发，免得有的用户第一个RFC达不成目标就提下一个。
同意。我个人认为提rfc是个很累的过程。一个月一个确实差不多。而且这样会更专注于已有的rfc上。很多rfc提了之后就弃了，最后也不了了之，与其如此，还不如就专注在一个rfc的follow through。
2.限制单一帖子下@管理员次数，或者出一个@全体投票管理员功能，一定时间内比如一周内只允许用一次，具体怎么做有待大家建议
不同意，本身管理员对rfc的参与就远远不够。如果只有缈缈几个管理员参与就算得票率过2/3，也没有太多的代表性。我认为RFC应该直接添加上每隔1天or2天就自动@所有管理员的功能。这样大家都可以看一看最新的RFC更改情况以及大家的意见，也可以随时在计票结束前改变意见。
重要的话重复三遍：
“我也认为管理员拥有权限与接受通知的义务是绑定的”
“我也认为管理员拥有权限与接受通知的义务是绑定的”
“我也认为管理员拥有权限与接受通知的义务是绑定的”
你如果觉得这是信息污染，大可以退出不当管理员。但是，把别人的辛苦和好意描述成“信息污染”，我个人觉得非常受冒犯。你以为我想在129下面每俩天@一遍所有人？有眼睛的都看到129是有人莫名其妙来找茬的，而且还出了130企图直接制止129，并且在130里质疑我是否有发RFC的资历？在130被admin锁了之后，此人还来129继续找茬从头到尾都不投票，就是不停地对过程和结果质疑，并且还抓住我的一个“选择性眼瞎”的描述来举报我。我最后不得不举报此人碰瓷，2样2simple选择了折叠帖子处理。此事才算告一段落。
在有人如此找茬的情况下，我个人认为我已经背负上了很大的压力去方方面面考虑129这个提案试图legitimize it，让意见传达到每一个管理员。所以我选择了每俩天@一次的方式，一遍一遍提醒每一个管理员你们有权利在计票结束之前随时改变你们的投票，也不停提醒没有投票的每一位管理员，我的宣传和提醒责任已经尽到。试图minimize任何计票结果出来之后的异议。
而这一切被你说成是“信息污染”？不好意思对这个说法我特么不接受！
3.根据《罗伯特议事规则》建立排期制度，在之前的RFC结束前，可以发新的pre-RFC，但自动进入锁定状态，上一RFC结束后，按照顺序解除其锁定状态并进行讨论。
不同意。原因认同懦夫斯基
4.pre-RFC需要5人联署才能进入正式排期,可能需要开发一条联署功能，或根据点赞管理员达到5赞，普通用户+管理员达到10赞，算联署成功。（根据Pumpkin和懦夫斯基的建议特此补充）
不同意，增加RFC提议成本，没有必要。
同意。我个人认为提rfc是个很累的过程。一个月一个确实差不多。而且这样会更专注于已有的rfc上。很多rfc提了之后就弃了，最后也不了了之，与其如此，还不如就专注在一个rfc的follow through。
2.限制单一帖子下@管理员次数，或者出一个@全体投票管理员功能，一定时间内比如一周内只允许用一次，具体怎么做有待大家建议
不同意，本身管理员对rfc的参与就远远不够。如果只有缈缈几个管理员参与就算得票率过2/3，也没有太多的代表性。我认为RFC应该直接添加上每隔1天or2天就自动@所有管理员的功能。这样大家都可以看一看最新的RFC更改情况以及大家的意见，也可以随时在计票结束前改变意见。
重要的话重复三遍：
“我也认为管理员拥有权限与接受通知的义务是绑定的”
“我也认为管理员拥有权限与接受通知的义务是绑定的”
“我也认为管理员拥有权限与接受通知的义务是绑定的”
你如果觉得这是信息污染，大可以退出不当管理员。但是，把别人的辛苦和好意描述成“信息污染”，我个人觉得非常受冒犯。你以为我想在129下面每俩天@一遍所有人？有眼睛的都看到129是有人莫名其妙来找茬的，而且还出了130企图直接制止129，并且在130里质疑我是否有发RFC的资历？在130被admin锁了之后，此人还来129继续找茬从头到尾都不投票，就是不停地对过程和结果质疑，并且还抓住我的一个“选择性眼瞎”的描述来举报我。我最后不得不举报此人碰瓷，2样2simple选择了折叠帖子处理。此事才算告一段落。
在有人如此找茬的情况下，我个人认为我已经背负上了很大的压力去方方面面考虑129这个提案试图legitimize it，让意见传达到每一个管理员。所以我选择了每俩天@一次的方式，一遍一遍提醒每一个管理员你们有权利在计票结束之前随时改变你们的投票，也不停提醒没有投票的每一位管理员，我的宣传和提醒责任已经尽到。试图minimize任何计票结果出来之后的异议。
而这一切被你说成是“信息污染”？不好意思对这个说法我特么不接受！
3.根据《罗伯特议事规则》建立排期制度，在之前的RFC结束前，可以发新的pre-RFC，但自动进入锁定状态，上一RFC结束后，按照顺序解除其锁定状态并进行讨论。
不同意。原因认同懦夫斯基
4.pre-RFC需要5人联署才能进入正式排期,可能需要开发一条联署功能，或根据点赞管理员达到5赞，普通用户+管理员达到10赞，算联署成功。（根据Pumpkin和懦夫斯基的建议特此补充）
不同意，增加RFC提议成本，没有必要。
理解部分管理员想要比较考虑仔细的rfc才通知他们表决，而不是从头到尾参与讨论。
反对123，原因
就像之前ambulance的rfc139里我认为，我不偏向复杂化开发，或者设置更多的例如参数值，觉得以后会增加改动数字“黑箱”风险和不可预知性，当然到时候可以发rfc修改啦。但尽量想出简约扁平化的点子比较好的，好像也符合开发者最近的财政紧张？
所以，不同意设置rfc，at所有人的时间间隔，以及排期制度。
同意4，建议和原因
同意pumpkin联署的想法，也同意懦夫司机防止联署抱团恶意操纵的顾虑，同意ambulance和hiyoall管理员要权利义务对等。
还有我发觉现在rfc讨论的有两类：
一是规则，例如126习惯法惩罚分类／128禁止广告／129修改习惯法／大家心心念念的上诉规则、弹劾规则，这些是最终是应该归纳到习惯法，所有人都suppose遵守。
二需要更改开发，那要admin真人做（所以admin真人事实上有一票否决权），例如132增加投票／133增加
因此，我建议连署人必须有一个超管。因为超管能把握rfc的时间密度，比较清楚有感知改动的操作难点和可行性。
因此我想rfc整理一下可以是这么一个流程：
1.［pre－rfc－v1］at最近活跃的你觉得能给意见的，但不能at所有人。不需要设置时间限制，也继续发在站务区，方便热心的普通用户和管理员来给意见。pre－rfc第一版本，最后要做出yes or no两个选项，rfc要有一个以上超管联署。
2.［rfc-v1］at所有人投票，通知结果。
如果yes，则联系admin改《习》《管》。如果no，发回pre－rfc－v2做第二版本更改，同样要有超管首肯。
这样就是被找上的超管要比较负责、有定力就是了。
反对123，原因
就像之前ambulance的rfc139里我认为，我不偏向复杂化开发，或者设置更多的例如参数值，觉得以后会增加改动数字“黑箱”风险和不可预知性，当然到时候可以发rfc修改啦。但尽量想出简约扁平化的点子比较好的，好像也符合开发者最近的财政紧张？
所以，不同意设置rfc，at所有人的时间间隔，以及排期制度。
同意4，建议和原因
同意pumpkin联署的想法，也同意懦夫司机防止联署抱团恶意操纵的顾虑，同意ambulance和hiyoall管理员要权利义务对等。
还有我发觉现在rfc讨论的有两类：
一是规则，例如126习惯法惩罚分类／128禁止广告／129修改习惯法／大家心心念念的上诉规则、弹劾规则，这些是最终是应该归纳到习惯法，所有人都suppose遵守。
二需要更改开发，那要admin真人做（所以admin真人事实上有一票否决权），例如132增加投票／133增加
因此，我建议连署人必须有一个超管。因为超管能把握rfc的时间密度，比较清楚有感知改动的操作难点和可行性。
因此我想rfc整理一下可以是这么一个流程：
1.［pre－rfc－v1］at最近活跃的你觉得能给意见的，但不能at所有人。不需要设置时间限制，也继续发在站务区，方便热心的普通用户和管理员来给意见。pre－rfc第一版本，最后要做出yes or no两个选项，rfc要有一个以上超管联署。
2.［rfc-v1］at所有人投票，通知结果。
如果yes，则联系admin改《习》《管》。如果no，发回pre－rfc－v2做第二版本更改，同样要有超管首肯。
这样就是被找上的超管要比较负责、有定力就是了。
4.才能进入正式排期,可能需要开发一条联署功能，或根据点赞管理员达到5赞，普通用户+管理员达到10赞...
"我也认为管理员拥有权限与接受通知的义务是绑定的"
这句话是有问题的，管理员的权限和义务并没有绑定，认为绑定是不是加戏了，你可以@超管来确认这一点。
“你如果觉得这是信息污染，大可以退出不当管理员。”
这句话也是加戏了，这也是超管的权限，你这么推理要么是谬误滑坡，要么是在要求不属于你权限外的事情。这句话正确的唯一情况是在超管准确定义管理员权限和接受通知的义务一定要强行绑定。
这段时间有些RFC和管理员操作手册第七条已经有冲突了。
（鼓励管理员识别到对尚未界定，但认为不合适的行为发起讨论。但是不鼓励在没有足够理由的条件下要求修改已经反复确认的规则。至少你得准备比当初支持该条例的管理员准备更有力的理由和事实来支持这个修改主张。）
之所以没有引起争议，是因为很多管理员并没有充足的时间用在改规则上，反复核对新的RFC和旧的（已通过的）有没有冲突。做后者的成本相当之高，可能需要人请假在家一周专门干这个事情才能防止出现新旧RFC冲突，但如果情况持续恶化的话我是不介意请假在家的 XD
反对123，原因就像之前ambulance的rfc139里我认为，我不偏向复杂化开发，或者设置更多的...
1并不需要复杂化开发，只要谁违反了就删除即可。2的话确实麻烦一点。
3也不需要复杂开发，也是现有的机制下谁违反了就删除rfc就行。
除了开发复杂，我指的是参数复杂。例如你增加了单个用户发rfc时间间隔这个参数是一个月，那以后大家发觉太憋屈是不是有得改成两周，或者以后人多了就算参数是一个月，也会经常很多人发rfc，是不是又得改成两个月。
除了开发复杂，我指的是参数复杂。例如你增加了这个参数是一个月，那以后大家发觉不合适是不是有得改成两周...
所以排期加联署也很重要，pre-RFC 排期是限制整体的，你发了联署不够也通不过，双重限制下再多人发也没关系。联署也能确保重要的RFC优先审阅
同意1。
其他两个我无所谓，认为并不重要。只要1实现了，就不会出现RFC泡沫了。
其他两个我无所谓，认为并不重要。只要1实现了，就不会出现RFC泡沫了。
所以排期加联署也很重要，pre-RFC 排期是限制整体的，你发了联署不够也通不过，双重限制下再多人发...
其实有联署就够了，看到堆积的rfc比较多新的又不是特别紧急，就可以暂时先压一下。现实中的议事流程也是内部协调的，这方面没必要规定得太死板。
反对123，原因就像之前ambulance的rfc139里我认为，我不偏向复杂化开发，或者设置更多的...
除了必须有一个超管联署其它都赞同。超管不一定对开发周期会有足够认识，如果只是改改参数做起来很快，但牵涉到增加新功能都要花不少时间。而且这样也变相授予了超管一项额外的权力，建议订立任何规则都不要随便授权。
任何牵涉新功能开发的方案，应当在pre-RFC讨论完成后由admin（开发者团队）审理，在确认可以进行功能排期的状态下实行表决。
我想如果有连署，特别是超管连署就不会有爆议程的问题了，因为超管懂得谨慎地同意或者不同意连署。超管控制同一个时段只有一个［rfc］和一个［pre－rfc］就行，这个工作量不大吧，因为我那个设置rfc就是yes or no，［pre－frc］你不感兴趣可以不参加。
如果已经有两个在了，超管可以拒绝连署请求并删帖先，但是我觉得发起的管理员也没那么傻啦。。
这个改动貌似简单一点？
其实反对123不是我强烈反对，只是提出路线之别的反对。但是4连署我是同意的，至于怎么连可以再斟酌。
如果已经有两个在了，超管可以拒绝连署请求并删帖先，但是我觉得发起的管理员也没那么傻啦。。
这个改动貌似简单一点？
其实反对123不是我强烈反对，只是提出路线之别的反对。但是4连署我是同意的，至于怎么连可以再斟酌。
只有admin真人大老板才能改开发吧。其它超管是威望400以上管理员，他们有少数几个能登录admin的公共账号删账号，改帖子《习》《管》。
找超管的原因主要是：超管能把握rfc的时间密度，比较清楚有感知规则改动的操作难点和可行性。这些跟开发都无关。
找超管的原因主要是：超管能把握rfc的时间密度，比较清楚有感知规则改动的操作难点和可行性。这些跟开发都无关。
只有admin真人大老板才能改开发吧。其它超管是威望400以上管理员，他们能登录admin的公共账号...
我还是觉得不应当随便授权，特别是把一项权力授予绝对少数的群体。如果真的担心渗透或者抱团，要求联署者必须都为正式管理员就行了。
其它超管是威望400以上管理员，他们能登录admin的公共账号删账号，改帖子《习》《管》。
据我所知他们没有这些权限，只有“以admin账号名义发言”这个选项。
你葱现在应该通常没人登录admin账户。
前几天还看见admin发帖然后留言自己反对自己呀？而且《习》《管》里面说欢迎大家修改，可是我没有修改...
https://pincong.rocks/article/10611。应该是指用户提出自己的修改意见，通过后由站长/站长又选出来的admin账户分享者来改。
我见了几次你葱超管看着帖子不能改的情况。https://pincong.rocks/article/10692。
前几天还看见admin发帖然后留言自己反对自己呀？而且《习》《管》里面说欢迎大家修改，可是我没有修改...
之前下放修改文章权限，本是为了修改站务信息/修改其他用户泄露的个人资料。
但是有两个有权限的超管滥用以后就废弃了。
所以现在站长选出来的admin账户分享者是固定的吗，公开的吗。
甚至可能现在没有admin分享者了。以前不公开。更多信息我不知道。
你葱十月战争就是两群admin账户分享者的矛盾。
"我也认为管理员拥有权限与接受通知的义务是绑定的"这句话是有问题的，管理员的权限和义务并没有绑定，认...
不好意思，我对这个绑定的理解不是单限于管理员的。是我个人对于权限和义务都有天然绑定的理解。
你若认为你作为超管，你拥有权限，但是你却不被义务绑定。那么很可以解释为何你会如此回复我，用“加戏”这种并不友善的说辞，我确实又一次感觉到我被你冒犯到。
并且一再提醒我所谓的“超管”的权限，或者要求我@超管，是否是想提醒我你是超管，所以超越我们普通管理员之上？所以你认为所谓的权限与义务的绑定对你这类“超管”来说就是不存在的？
并且就在我已经在上篇提及，我感到受到冒犯的情况下，我都没有收到你任何道歉，并且这次又收到了“加戏”这种很有攻击意味的说辞。
是不是作为超管，让你自我感觉特别良好？所以你也无视别人提及的受冒犯？所以你也觉得你用那种语言去描述别人的努力和付出无需道歉？！
回复 超过400威望匿名自动是admin。
有權限更改文章的那位是站方的人，前台現在的事情要透過他，但其他高聲望者也能夠匿名使用admin沒錯。
其實提RFC也就是一陣一陣的，這陣子比較密集，過不久又沉寂下去。畢竟現在開發人力有困難，不大可能有重大改動。我自己暫且不投任何票。
我想令狐沖也未必有要否定您所推動議程的意思。前陣子確實RFC較多，而且非常明顯的無效議案又佔了大半。...
他自己可没有这么解释。你不需要为他解释。他从头到尾无对他的言辞有道歉的意思，回复我开口闭口“超管”又给我扣上了一个“加戏”的帽子。
我想令狐沖也未必有要否定您所推動議程的意思。前陣子確實RFC較多，而且非常明顯的無效議案又佔了大半。...
我并没有否定129议程，我只是觉得一上线就是全是RFC的通知很不合理。这是我认为需要改革的理由
@令狐冲 目前为止，尽管我赞成该RFC方向，但我认为需要进一步修改，所以对此法案持反对态度，原因如下:
赞同此方向，但不赞同在数量上做硬性规定，见 @Geena 的反对意见:
建议修改成：一名用户同时只能提出一个RFC（发布征求意见稿的数量不限），在前一RFC未表决完成前，RFC发起者，及联署者名下的其它RFC不能进入表决程序。
建议删去此条。本条并没有可执行的具体细则，且该条款与 RFC-134】RFC类型的贴子增加自动通知全部管理员功能 雷同，应当先去推动RFC-134的表决，而非在此另立条款。
赞成该条方向，但在细节上需要进一步确认：pre-RFC仅为“征求意见稿”，不应作任何限制，也不应有编号，只有进入正式表决程序中的RFC才可加上编号。“根据《罗伯特议事规则》建立排期制度”定义过于宽泛，不是一个可操作性的制度，需要进一步明确排期制度的细节。例如，是否需要有管理员负责议事和表决流程，在这方面尚未有共识。
赞同此条方向，但目前在细节上还有不同意见，仍需要进一步讨论以形成共识。
本RFC非常重要，实际上确定了今后的议事流程，需要慎重讨论。建议先进行修订，并试着让更多人参与到讨论中，不要在细节未确认的情况下立即对本RFC进行表决。
1.限制每个账号每月RFC提出数量，就像一般现实中议会运行那样。一人一月最多一次，确保了RFC的质量再发，免得有的用户第一个RFC达不成目标就提下一个。
赞同此方向，但不赞同在数量上做硬性规定，见 @Geena 的反对意见:
除了开发复杂，我指的是参数复杂。例如你增加了单个用户发rfc时间间隔这个参数是一个月，那以后大家发觉太憋屈是不是有得改成两周，或者以后人多了就算参数是一个月，也会经常很多人发rfc，是不是又得改成两个月。
建议修改成：一名用户同时只能提出一个RFC（发布征求意见稿的数量不限），在前一RFC未表决完成前，RFC发起者，及联署者名下的其它RFC不能进入表决程序。
2.限制单一帖子下@管理员次数，或者出一个@全体投票管理员功能，一定时间内比如一周内只允许用一次，具体怎么做有待大家建议
建议删去此条。本条并没有可执行的具体细则，且该条款与 RFC-134】RFC类型的贴子增加自动通知全部管理员功能 雷同，应当先去推动RFC-134的表决，而非在此另立条款。
3.根据《罗伯特议事规则》建立排期制度，在之前的RFC结束前，可以发新的pre-RFC，但自动进入锁定状态，上一RFC结束后，按照顺序解除其锁定状态并进行讨论。
赞成该条方向，但在细节上需要进一步确认：pre-RFC仅为“征求意见稿”，不应作任何限制，也不应有编号，只有进入正式表决程序中的RFC才可加上编号。“根据《罗伯特议事规则》建立排期制度”定义过于宽泛，不是一个可操作性的制度，需要进一步明确排期制度的细节。例如，是否需要有管理员负责议事和表决流程，在这方面尚未有共识。
4.pre-RFC需要5人联署才能进入正式排期,可能需要开发一条联署功能，或根据点赞管理员达到5赞，普通用户+管理员达到10赞，算联署成功。
赞同此条方向，但目前在细节上还有不同意见，仍需要进一步讨论以形成共识。
本RFC非常重要，实际上确定了今后的议事流程，需要慎重讨论。建议先进行修订，并试着让更多人参与到讨论中，不要在细节未确认的情况下立即对本RFC进行表决。
@一只鹿兒 @苏维埃督战队 @admin @陈美丽 @InspectorBen @懦夫斯基 @荣誉非国民 @killreddragon @利维坦 @FreedomAsia @红冬里的青鱼 @anonymousLiu @waliesi @guibuhai @Tashkent @en010272 @viewer @rtgzddgh @tony231 @陪你去看毛新宇 @中国网警巡查执法 @令狐冲 @陈士杰 @姨湃湖岩 @chobe @小钙 @经略 @Alleria @balibali @炎黄子葱 @vvgvv1 @邓丽君 @第三新索多玛 @巴巴罗萨 @币圈奇葩8964 @组组组组 @疯狂习近平 @由比滨结衣 @還是小學生 @winkcat @时代革命 @Shekzara @magrabee @Pepperoni @小汪酱 @橘希实香 @若名用户 @Merlin @Hunter @清水照子 @月社妃 @社会煮役铁拳 @fb_china_today @niubility @jerry168 @HelicopterZ @LuvDDDD @pc6650 @Pracseeuvn @带带大师兄 @不存在 @仲长若谷 @Arthur_Fleck @ikuyui @马拉糕 @Ambulance @reppep @VR46 @2样2simple @nmff @韭菜地里一根葱 @Organsland @arashi8964 @江上风流胜习家 @維尼學跳舞 @黑杰克 @正義終將戰勝歸來 @眼镜娘阿锅 @吳樂天 @做个清醒的人 @民主信仰者 @守法刁民 @yogafire @逆流而上的鱼 @末代皇帝习禁评 @咸鱼老李 @幹乾干停用 @rgjdwte @Gogh9836 @拉法兒 @Meltdown @silaoye @自由党人 @米路庫 @润之的忏悔 @HenkGao @中华合众国 @路过一下 @唵嘛呢叭咪吽 @且翻且珍惜 @续命师归隐 @韭菜地里一支韭 @Android @zhengyi @上帝爱世人 @向往光明的韭菜 @Natasha @hiyoall @碴条 @Geena @书记 @鸡鸡 @大差不差 @Nakayama @Tseyu @burleigh @葱侠 @小狗包帝 @EPSON @安娜 @Benzene @lelouchgreat @匮名用户 @Sulaiman_Gu @江沢民 @我死了 @Nihilistra @kcyx2184 @mtw1994ja @Dualeagles @勃列日涅夫 @grantyang @品姜 @d444c @剑心 @Philadelphia @spark808 @广场青年 @anonym @孙金香 @avatar @Hermione @立紗Lisa @awuwu @trtrtr2 @专杀恶警不服就干 @普习金 @人性的曙光 @MyWolf @文不能測字 @bdcbdc @RandomID_1 @救救孩子 @jsglsjh @小哼哼lulu @荆棘之心 @asd123088 @ratdotlight @存在者09
同意1和2
3和4 我弃权
3和4 我弃权
d有道理，支持一个
最近这个版本，实际上就是恢复pre-RFC制度，禁止随便大量at他人。
我表示同意。
顺便吐槽，at全体这个做法，似乎最近一个月才开始出现，不知是谁先开始使用的，真想找出始作俑者敲打一顿。
1.限制每个账号每月RFC提出数量，就像一般现实中议会运行那样。一人一月最多一次，确保了RFC的质量再发，免得有的用户第一个RFC达不成目标就提下一个。超量的RFC可以无理由删除。
2.限制单一帖子下@管理员次数，在同一帖子下只允许@全体管理员一次，从@第二次开始，管理员可以删除。
3.排期制度，在之前的RFC结束前，可以发新的pre-RFC，可以讨论，但不允许@全体管理员。
4.pre-RFC需要5名管理员联署才能进入正式RFC排期，五名管理员点赞主楼即可，同时RFC提出者需要在主楼记录联署管理员名单。RFC没投票截止前，如有新开的RFC，管理员可以主动把该RFC锁定，直到旧的RFC投票结束后可以解锁。
我表示同意。
顺便吐槽，at全体这个做法，似乎最近一个月才开始出现，不知是谁先开始使用的，真想找出始作俑者敲打一顿。
同意同意同意，目前最烦的就是无穷无尽的rfc了，精简精简精简，全职的国会也没这么多法案要通过。
ousLiu ...
现在这个版本基本OK，我支持所有改动。
想到一个细节上的问题建议再微调一下：第三条的排期制度，是否规定一下可以同时表决的RFC数量（3个比较好）？因为一个RFC通常表决需要1-2周，如果不允许同时对多个RFC进行表决，容易造成表决流程缓慢，也有可能被恶意阻塞。
除此之外，是否考虑建立一个RFC专区，并置顶愿意讨论Pre-RFC的管理员列表，这样用户提出Pre-RFC的时候可以去@这些管理员，以方便得到反馈和联署？个人觉得本RFC今后也应当变成一个指引性的帖子置顶放在RFC专区。（这一点不必加在这个RFC上面，多开一个帖子和分区就行）
同意
我提RFC的时候看到很多都处于没下文的状态。所以当时暂且当作一个提建议的备忘录。
既然现在要制定频率数量的限制，是不是要推动之前的提案尽快落实？不仅仅是投票结束，也应该定个开发排期
我提RFC的时候看到很多都处于没下文的状态。所以当时暂且当作一个提建议的备忘录。
既然现在要制定频率数量的限制，是不是要推动之前的提案尽快落实？不仅仅是投票结束，也应该定个开发排期
1 和 2 同意
3 和 4 棄權
3 和 4 棄權
同意我提RFC的时候看到很多都处于没下文的状态。所以当时暂且当作一个提建议的备忘录。既然现在要制定频...
可以先整理一下之前的提案，不需要开发的可以落实，需要开发的整理出来开个排期。
admin
公共账号
1和2已通过，3和4未通过。