<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wikidot="http://www.wikidot.com/rss-namespace">

	<channel>
		<title>建议与政策：正在讨论 (new threads)</title>
		<link>http://lostmedia.wikidot.com/forum/c-7851842/</link>
		<description>论坛分类中的讨论串 &quot;建议与政策：正在讨论&quot; - 我们该怎样改进这个网站？在这里提出任何关于网站架构及政策的讨论及提问。</description>
				<copyright></copyright>
		<lastBuildDate>Wed, 15 Jul 2026 16:24:40 +0000</lastBuildDate>
		
					<item>
				<guid>http://lostmedia.wikidot.com/forum/t-18142795</guid>
				<title>关于标签申请的审查尺度问题以及延伸问题的讨论</title>
				<link>http://lostmedia.wikidot.com/forum/t-18142795/</link>
				<description>什么样的标签是一个合格的可申请标签？</description>
				<pubDate>Mon, 13 Jul 2026 11:45:02 +0000</pubDate>
				<wikidot:authorName>5M7</wikidot:authorName>				<wikidot:authorUserId>6624859</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>目前申请标签的评判基准模糊不清，导致申请者（成员）和站务（审查者）两个团体，甚至团体内部均存在认知偏差。这种情况导致了矛盾————<strong>申请者不知道申请什么样的标签合适、审查者不知道什么样的标签合格。</strong>所以为了解决该矛盾，应该对上述问题进行一个澄清。</p> <hr /> <p>目前站点可申请的标签现状有三类：地区归属、特性、IP标签。其中地区归属标签是严格自洽的<sup class="footnoteref"><a id="footnoteref-188881-1" href="javascript:;" class="footnoteref" >1</a></sup>，其余两种标签存在模糊不清的可能性。因此个人觉得，为了解决另两类标签的认知偏差，大致可以分为以下两个方向的方案。</p> <ul> <li><strong>将标签申请初始化权限完全收回，确保定义中心化减少歧义。</strong></li> </ul> <p>这意味着今后标签不再由其他成员提出定义，而是由站务内部来定义或判定。因为矛盾来源于双方，那么将定义权收回可以直接减少一方矛盾，而站务本身人数明显少于非站务人数，矛盾量必然更少，自洽率更高。</p> <p>具体表现在，申请中心的标签申请直接裁撤<sup class="footnoteref"><a id="footnoteref-188881-2" href="javascript:;" class="footnoteref" >2</a></sup>，所有标签全权由站务负责增、删、改、定。</p> <ul> <li><strong>将标签申请的门槛尽可能降低，理解、定义、使用权尽可能交给社区成员。</strong></li> </ul> <p>这意味着站务只做最最基本的判断<sup class="footnoteref"><a id="footnoteref-188881-3" href="javascript:;" class="footnoteref" >3</a></sup>，其余关于标签的理解、定义、解释、使用交给社区的编者成员自己。因为矛盾主要来源于认知不匹配，站务在客观上不可能知道所有LM媒体的所有方面知识，相当于矛盾双方把站务这方剔除了。不过与上一个方法相比，这种方案自洽率不会很高，因为非站务人员的素质参差不齐且人数更多，极端的情况会引发标签编辑战<sup class="footnoteref"><a id="footnoteref-188881-4" href="javascript:;" class="footnoteref" >4</a></sup>或者新的定义延伸问题讨论<sup class="footnoteref"><a id="footnoteref-188881-5" href="javascript:;" class="footnoteref" >5</a></sup>，届时需要站务最后拍板。</p> <p>具体表现在，申请中心的形式保持不变<sup class="footnoteref"><a id="footnoteref-188881-6" href="javascript:;" class="footnoteref" >6</a></sup>，但<strong>要求任何申请者更加严格的填写一个标签申请的内容，至少包含命名、简述、定义、符合条件的内容，毕竟这种申请站务不再过问的话，以后出现争议需要以申请内容的相关定义作为凭据让站务更好的拍板。</strong>另外，在标签的使用表现上，编者可以凭借自己的主观理解使用添加<sup class="footnoteref"><a id="footnoteref-188881-7" href="javascript:;" class="footnoteref" >7</a></sup>标签，站务无需过多过问理解，类似于B站的标签使用方式<sup class="footnoteref"><a id="footnoteref-188881-8" href="javascript:;" class="footnoteref" >8</a></sup>。</p> <div class="footnotes-footer"> <div class="title">脚注</div> <div class="footnote-footer" id="footnote-188881-1"><a href="javascript:;" >1</a>. 国家与地区的归属标签命名是简约确定的、争议极少的、无法虚构的、有穷尽的，因此几乎不可能出现认知偏差。</div> <div class="footnote-footer" id="footnote-188881-2"><a href="javascript:;" >2</a>. 或者退化成一种申请词条符合某个现成的标签的形式。这里仅是举例。</div> <div class="footnote-footer" id="footnote-188881-3"><a href="javascript:;" >3</a>. 比如名称不能太抽象、不能有一样的命名或非法字符命名等。</div> <div class="footnote-footer" id="footnote-188881-4"><a href="javascript:;" >4</a>. 词条的历史记录出现某某添加A、某某删除A的反复问题。</div> <div class="footnote-footer" id="footnote-188881-5"><a href="javascript:;" >5</a>. 比如帖子“XXX是否属于XXX，这样不会有问题吗？”</div> <div class="footnote-footer" id="footnote-188881-6"><a href="javascript:;" >6</a>. 一些关键的、管理的标签自然不会开放。</div> <div class="footnote-footer" id="footnote-188881-7"><a href="javascript:;" >7</a>. 仅限申请的，且不包含严格自洽的地区标签。</div> <div class="footnote-footer" id="footnote-188881-8"><a href="javascript:;" >8</a>. 从管理类组件方面，这种自由的使用需要和统计类组件的逻辑解耦。</div> </div> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://lostmedia.wikidot.com/forum/t-18121284</guid>
				<title>关于演出音乐的界定问题</title>
				<link>http://lostmedia.wikidot.com/forum/t-18121284/</link>
				<description></description>
				<pubDate>Fri, 10 Jul 2026 04:35:15 +0000</pubDate>
				<wikidot:authorName>XHG78999</wikidot:authorName>				<wikidot:authorUserId>6999474</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>rt，<a href="https://lostmedia.wikidot.com/forum/t-18114956/danfengchaoyang#post-8490488">《丹凤朝阳》讨论串</a>转移而来。</p> <p>有一些音乐作品，比如民族管弦乐这类艺术性作品，很多情况下其传播和发行依靠各类演出，与目前“音频”类目常收集的，在录音棚或电脑内制造并发行的音乐作品相去甚远。这个差异导致目前填词条时出现了部分争议。在此陈述一些我的观点，以供讨论，鄙人不才，还请手下留情。</p> <p><strong>一、记录和记录形式</strong></p> <p>首先我支持将这类音乐的演出资料界定为媒体。对这些乐曲的记录，其重点并不在于某场演出，因为一首曲子可以根据背景被编入千千万万的演出之中，它的独立性是由音乐媒介的性质决定的。</p> <p>目前大部分音乐演出的资料都是视频，因为除了乐曲本身，乐队配置、指挥等细节也是鉴赏此类音乐必须考量的。从资料本身的性质来看，这类音乐的条目应该标记为视频。这也是我写《印象良渚》条目的时候得到的答复。</p> <p>但是，界定一首乐曲独立性的依据是旋律，在大家可感的前提下，其侧重点应当是承载旋律的音频，而视频只不过携带了旋律表达的副产物罢了。剥离其附加的乐队配置等信息（对于绝大多数曲子这不是区分其独立性的依据），标记为音频的话也许可以更加着重地突出这种媒体的性质。</p> <p>最后是对于乐谱的划分问题。原始乐谱是乐曲旋律的根源<sup class="footnoteref"><a id="footnoteref-297301-1" href="javascript:;" class="footnoteref" >1</a></sup>，有部分学者认为，记谱语言可以算作部分表意文字<sup class="footnoteref"><a id="footnoteref-297301-2" href="javascript:;" class="footnoteref" >2</a></sup>，那么系统性的记谱就可以属于文本媒体的一种。不过，按照现有条件，大部分乐谱只能通过图片的形式呈现，从媒介本身的性质又得界定为图片——不过由于它的重点并不在图片展示的景象的独特性，因而我个人不是特别赞同这种划法。</p> <p><strong>二、独立版本问题</strong></p> <p>这类音乐作品通常有明确的体例划分，且通常关系到区分一些相近的版本。比如说，目前已知的李博禅《楚颂》就有<a href="https://www.bilibili.com/video/BV14E411N7G4">二胡协+民族管弦乐团</a>、<a href="https://www.bilibili.com/video/BV1rT411q7kM">二胡协+西洋管弦乐团</a>、<br /> 二胡独奏（<a href="https://www.huain.com/article/erhu/2023/1220/2440.html">此处</a>提及，我没有找到较为权威的演出视频）、<a href="https://www.bilibili.com/video/BV1c3411M7CT">二胡+钢琴重奏</a>、<a href="https://www.bilibili.com/video/BV1X44y1a7sL">笛子+西洋管弦乐团</a>、<a href="https://www.bilibili.com/video/BV18T411u71g">笛子+民族管弦乐团</a>、甚至（我个人听说）个别乐团自行修改的民族管弦乐合奏等种种独立配器乐谱版本<sup class="footnoteref"><a id="footnoteref-297301-3" href="javascript:;" class="footnoteref" >3</a></sup>。如果再添加各类乐团可能的临时删减，把他们都单独划分版本，再标丢失找回，将产生巨量的重复条目。考虑到它们之间的链接性质，我倾向于将它们作为同一首乐曲进行处理，而不是划分为合集，因为其核心旋律依旧是相同的。</p> <p>另外，在旋律一致、音色没有大致变更的前提下，我认为不应该按照声乐标准对这类音乐区分所谓“翻唱”与否，不同乐队演奏同一曲目，除了可能的停顿处理和速度外的差异几乎可以忽略。</p> <p>另外还有“移花接木”问题。此前《印象良渚·光耀东方》变成《颂江南》，个人听下来开头的鼓段似乎有细微差异，按照前面提到的标准则应当同样划入《印象良渚》的条目，但是演出方对待这些经过少量修改的复制内容是当作全新的独立作品的，这和目前已经有的重新剪辑片段有性质区别。出于方便记录的目的，我认为可以继续保留他们是原曲目部分。如果移花接木的片段失传了，原片段可以作为平替，反之亦然。</p> <p>以上是目前编辑中发现的问题，不吝赐教。若有其余问题，后续再补充。</p> <div class="footnotes-footer"> <div class="title">脚注</div> <div class="footnote-footer" id="footnote-297301-1"><a href="javascript:;" >1</a>. 这里暂时排除由音视频资料反推的“扒谱”，这些东西我倾向于认为是一种复原。</div> <div class="footnote-footer" id="footnote-297301-2"><a href="javascript:;" >2</a>. 所谓部分表意就是指这套系统只能呈现特定种类的信息，局限于特定领域的活动。举例来说，拉丁文、古埃及象形文字和盲人点字都能够完整表意，不论是税条、史书、商业法律，或是情诗和历史著作，全部难不倒它。相较之下，最早的苏美尔文字就像是现代的数学符号和音乐符号，只能部分表意。例如数学符号虽然能用来计算，但要写情诗就做不到了。——《人类简史》</div> <div class="footnote-footer" id="footnote-297301-3"><a href="javascript:;" >3</a>. 似乎还有笙+笛室内乐、笙+笛+钢琴重奏等等版本，但是都不是正规乐团演出。我没有条件直接去版权库翻有没有独立版本的乐谱，大概率是自改，这里按下不表。</div> </div> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://lostmedia.wikidot.com/forum/t-18076190</guid>
				<title>关于站务申请</title>
				<link>http://lostmedia.wikidot.com/forum/t-18076190/</link>
				<description></description>
				<pubDate>Sat, 04 Jul 2026 14:10:40 +0000</pubDate>
				<wikidot:authorName>IDOMOY</wikidot:authorName>				<wikidot:authorUserId>9310011</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>站务申请开放后，出现了不少问题，所以目前先暂时关闭了，单开个帖子讨论下，等有结果了再看怎么办。</p> <p>首先是有几位MAST在任职没多久的情况下直接去申请版主甚至管理员，只能说不要太着急，刚任职的新手还有很多要学习的，有没有能力承担更高的职责也还看不出来，所以先做好当下吧</p> <ul> <li>管理员单独拎出来说，从<a href="http://lostmedia.wikidot.com/meet-the-staff">站务团队</a>能看出目前管理员和版主的数量是失衡的，这点要怪我之前放权太松了。<strong>管理员其实是站点需求最低的职位</strong>，有3人都完全足够了，因为后台面板的操作频率要远远低于其他前台事务。并且大部分人任这个职位也只有个权限最高的形式，并不具备主导站点事务的能力，在这里堆人数毫无意义。</li> </ul> <p>目前站务的数量已具规模，维护站点运行是足足够用的，所以应该关注下其他的问题。除了上述的管理和版主数量失衡，也有站务申请只在有需求时非常态开放的提议。综合这些情况，个人对站务团队的运行提一些想法：</p> <ul> <li>限制管理员的任职途径和总人数，保证这个职位上的人稳定且可靠。例如出现管理员辞职缺位的情况时，考虑在社区公投票出新管理员。</li> <li>MAST和版主可以相对宽松，可以配套一些MAST升版主的要求，MAST申请则“只在有需求时非常态开放”。</li> <li>“MAST”可以考虑换个更直观的中文名字，例如“xx辅助”之类的。</li> </ul> <p>另外，个人觉得Wikidot的权限系统太过简陋，职位仅2种且是包含关系，导致权责难以对等，形式盖过实际。如果未来迁站后的新站点对这方面有所改善，咱们的站务体系也得与时俱进啊。</p> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://lostmedia.wikidot.com/forum/t-17971577</guid>
				<title>关于整合型媒体的定义、标签等相关问题</title>
				<link>http://lostmedia.wikidot.com/forum/t-17971577/</link>
				<description></description>
				<pubDate>Sat, 30 May 2026 16:03:18 +0000</pubDate>
				<wikidot:authorName>H_W</wikidot:authorName>				<wikidot:authorUserId>8108397</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p><sub>捞一下，接<a href="https://lostmedia.wikidot.com/forum/t-17954067#post-8171952" target="_blank">此话题</a>继续。</sub></p> <hr /> <p>目前而言就是，对于某类围绕 作者、制片公司等单一对象 为主，通过表格等方式列举出来一大批媒体间除前述的单一对象外无关联性的条目，如：</p> <ul> <li>以作者 <ul> <li><a href="http://lostmedia.wikidot.com/drwilly">Dr.Willy的作品（部分发现的Vocaloid职人作品；2008-2010年）</a></li> <li><a href="http://lostmedia.wikidot.com/samplingsampling">samplingsampling的作品（部分发现的Vocaloid职人音乐作品；2010-2013年）</a></li> <li><a href="http://lostmedia.wikidot.com/syudou">syudou的作品（部分发现的Vocaloid职人音乐作品；2010-2014年）</a></li> <li><a href="http://lostmedia.wikidot.com/utero-vocaloid">Utero的作品（部分发现的Vocaloid职人音乐作品；2009-2014年）</a></li> <li><a href="http://lostmedia.wikidot.com/koronba">ころんば的歌曲（部分发现的UTAU职人制作的系列歌曲；2008-2016年）</a></li> <li><a href="http://lostmedia.wikidot.com/yurrycanon">ユリイ・カノン（尤里卡农）的作品（部分发现的Vocaloid职人音乐作品；2013-2015年）</a></li> <li><a href="http://lostmedia.wikidot.com/daobaidezuoping">島白的作品（发现的Vocaloid职人作品；2008年之后）</a></li> <li><a href="http://lostmedia.wikidot.com/kannagi">巫的作品（部分发现的Vocaloid职人的音乐作品；2009-2011年）</a></li> <li><a href="http://lostmedia.wikidot.com/tiefengp">鉄風P的歌曲PV（部分发现的Vocaloid职人歌曲PV；2008-2009年）</a></li> </ul> </li> <li>以团体 <ul> <li><a href="http://lostmedia.wikidot.com/guohua">国华失传电影（部分发现的台湾电影公司的失传电影；1968-1985年）</a></li> <li><a href="http://lostmedia.wikidot.com/meiguoguohuitushuguan-weishibietuxiang">美国国会图书馆未识别图像（部分确定来源的人物图像合集；约2015年之前）</a></li> </ul> </li> <li>杂项 <ul> <li><a href="http://lostmedia.wikidot.com/puxianxiwuminglianpu">莆仙戏无名脸谱（部分确定来源的系列脸谱；2013年之前）</a></li> </ul> </li> </ul> <p>上文列举出的条目（除国华）基本均为其中单一组成媒体信息过少，不足以支撑其完整的条目，因而被整合为一个条目内。目前如我在<a href="https://lostmedia.wikidot.com/forum/t-17954067/">此</a>提到的，由于媒体资讯简化导致对此类条目的发现描述并不清晰，因此最终的结论是对这类条目新增标签，并放开对其的简化描述。</p> <hr /> <p>目前结论为：</p> <p><strong>特性标签：</strong>系列（待定）<br /> <strong>定义：</strong>该词条内容包含一系列与词条主题强关联的媒体的集合。</p> <hr /> <p>我个人意见：</p> <ol> <li>对标签名我不建议称作“系列”，其可能与管理标签“总览”产生歧义。个人认为需要更换</li> <li>对建立要求同5M7，为避免有人借此漏洞建立无意义的条目，因此建议为： <ol> <li>所包含的系列媒体，必须全部是符合站点收录标准的媒体</li> <li>“系列”词条内不能再包含“系列”媒体的情况</li> <li><sup>[个人建议]</sup>汇集组成的媒体数量应至少为10<sup>[数量待定]</sup>个媒体</li> <li><sup>[个人建议]</sup>其必须在某个特定的讨论串提出并经过职员的审核同意后才可进行创建页面</li> </ol> </li> <li>对格式，个人建议 <ol> <li>必须按照给定的模版进行编辑 <ol> <li>模版应当给出表格，表格表头需包括 媒体、时间、状态、发现时间、发现者、备注</li> </ol> </li> </ol> </li> </ol> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://lostmedia.wikidot.com/forum/t-17947232</guid>
				<title>个人对精品推荐的一些想法</title>
				<link>http://lostmedia.wikidot.com/forum/t-17947232/</link>
				<description></description>
				<pubDate>Sun, 24 May 2026 02:59:52 +0000</pubDate>
				<wikidot:authorName>IDOMOY</wikidot:authorName>				<wikidot:authorUserId>9310011</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>新的精品制度也运行<strong>一整年</strong>了，工作中表露出来的问题也不少，本人在此聊聊自己的感受和看法，也是希望<strong>借这个契机大刀阔斧地优化一下这个栏目</strong>。</p> <p>关于栏目的意义，既然叫“<strong>精品推荐</strong>”，自然是把站内写得好的优秀词条单独展览出来，形成一种<strong>正反馈的激励</strong>，延续创作热情，有利于站点长期运行。但是当前的标准与其有不契合之处：</p> <p>一，规定一期4~6个，可选数量不够就跳过，实际上有点带歪了工作重心。群里每月讨论的时候，会去关注词条够不够数，要不要想办法凑，且默认会有位置给新发现的老媒体。实际上从鼓励创作的角度来看，<strong>一期只有一两个或多达七八个也没什么问题</strong>，实事求是有多少就放多少，避免为了凑数降低标准，该推荐的词条不拖延也能更好的保护创作热情。</p> <p>二，虽然我一直设法淡化标准中“最近发现”这个要素，但当前的精品推荐似乎仍会给人留下“这是个展示最近发现的栏目”的印象，每月的推荐帖中仍会出现“最近发现”被推荐并吸引大量附议的情况。个人坚持认为这不是一个好现象，站内资讯功能推出后，这两个功能<strong>理应各司其职</strong>，<strong>有重叠但不喧宾夺主</strong>，继续在精品推荐中加入“最近发现”只会让栏目<strong>标准含混</strong>、<strong>意义不纯净</strong>。</p> <p>并且从另一个角度说，老词条上推荐本身没问题，一些<strong>非常优秀但被忽略的遗珠也值得被发掘</strong>，但现在的老词条推荐<strong>全被“最近发现”占去</strong>，也使得这方面的意义<strong>完全无法实现</strong>。</p> <p>综合这些想法，个人有以下建议：</p> <ul> <li>删去第一点中提到的<strong>每期个数限制</strong>，能规避为了凑数带“最近发现”上场，将标准重心转回到词条本身的质量上。此举的其他意义见上文。</li> <li>今后的工作中<strong>明确区分</strong>“优秀新词条”和“遗珠老词条”，推荐帖可以规定推举时附带词条所属的类型，展示窗口可将两者用隔线分开。</li> <li>“老词条遗珠”可以兼容“最近发现”的要素，若一个老词条在当月被FOUND，同时其质量优秀足以被推荐，属于遗珠，自然可以兼容，但<strong>不能倒果为因</strong>（指以“最近发现”为先决条件去找其中优秀者），“精品推荐”的底层逻辑就应该是质量优先。</li> </ul> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://lostmedia.wikidot.com/forum/t-17646909</guid>
				<title>是否额外在讨论区填加词条归档的通知板块？</title>
				<link>http://lostmedia.wikidot.com/forum/t-17646909/</link>
				<description>rt</description>
				<pubDate>Wed, 25 Mar 2026 08:25:50 +0000</pubDate>
				<wikidot:authorName>5M7</wikidot:authorName>				<wikidot:authorUserId>6624859</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>目前关于词条的重要修订操作<sup class="footnoteref"><a id="footnoteref-803132-1" href="javascript:;" class="footnoteref" >1</a></sup>的通知均在页面的讨论区，一是占用了原本词条的讨论位置，二是不能及时的反馈给相关人员，三是有时候部分人员可能会忘了添加相关说明，因此是否可以在讨论区添加“词条页面修订通知”之类的板块<sup class="footnoteref"><a id="footnoteref-803132-2" href="javascript:;" class="footnoteref" >2</a></sup>，作为修订操作的声明？</p> <div class="footnotes-footer"> <div class="title">脚注</div> <div class="footnote-footer" id="footnote-803132-1"><a href="javascript:;" >1</a>. 本串主要讨论归档，但实际上亦包含重写、重定向等大幅度修订操作。</div> <div class="footnote-footer" id="footnote-803132-2"><a href="javascript:;" >2</a>. 可类比SCP-CN的讨论区通知板块。</div> </div> 
				 	]]>
				</content:encoded>							</item>
					<item>
				<guid>http://lostmedia.wikidot.com/forum/t-16985141</guid>
				<title>本版规范</title>
				<link>http://lostmedia.wikidot.com/forum/t-16985141/</link>
				<description></description>
				<pubDate>Wed, 13 Nov 2024 06:21:32 +0000</pubDate>
				<wikidot:authorName>IDOMOY</wikidot:authorName>				<wikidot:authorUserId>9310011</wikidot:authorUserId>				<content:encoded>
					<![CDATA[
						 <p>本版为建议与政策讨论板块，成员在此可以<strong>对站点政策和功能提出建议或疑问</strong>，可以<strong>报站点各方面存在的bug</strong>，也可以<strong>提请新功能</strong>。</p> <ul> <li>成员应清晰描述自己的疑问或建议，必要时可以附带理由或论证；</li> <li>同一讨论串应尽量只讨论一个问题，问题较为复杂的情况下可以拆分讨论；</li> <li><strong>讨论结束</strong> / <strong>作废</strong> / <strong>15天无回复</strong> 的讨论串，将视情况转移至其他板块。</li> </ul> 
				 	]]>
				</content:encoded>							</item>
				</channel>
</rss>