插件接收工作

[alex3236]

#219 的扩展讨论。目前的两个问题如下：

Checklist 不工作

应该是权限问题，需要仓库所有者调整；Checklist 是否必要？

插件“审核”与“通过”没有特定标准

• 更完善的标准？
• 也许可以学习其他类似项目，调整权限和工作流，例如 PR 仅在两位 CatalogueMaintainer Approve 后自动合并。

[AnzhiZhang]

支持建议更完善的接受标准，目前的标准是一个类似于“底线”的标准。
两位approve看起来不错，一位approve然后N日后自动合并似乎也是个好主意

[AnzhiZhang]

为了鼓励避免重复造轮子，提出一个想法：同功能的插件只接收一个。

1. 如有更新需求，先到原仓库讨论和pr，若作者愿以开放的开源态度共同合作，可避免重复造轮子
2. 若作者不再维护或长期未回复，可自行创建仓库或在社区创建，继续维护插件，原插件从插件库下架或archive
3. 若方向分歧较大或作者不乐意合作，符合接收标准，接受两个插件，由用户自行选择

[alex3236]

2. 若作者不再维护或长期未回复，可自行创建仓库或在社区创建，继续维护插件，原插件从插件库下架或archive

Inactive 如何定义？人工确定吗？

[yuyi2439]

为了鼓励避免重复造轮子，提出一个想法：同功能的插件只接收一个。

1. 如有更新需求，先到原仓库讨论和pr，若作者愿以开放的开源态度共同合作，可避免重复造轮子
2. 若作者不再维护或长期未回复，可自行创建仓库或在社区创建，继续维护插件，原插件从插件库下架或archive
3. 若方向分歧较大或作者不乐意合作，符合接收标准，接受两个插件，由用户自行选择

关于第二点，我建议在archive后允许续作者修改原作者的插件介绍页面，可以添加新插件的链接，并且说明此插件已停更。
等到原作者回应了续作者在插件仓库的pr后，并且续作者也回复了，即可进行第1和3点的流程。

关于archive插件的恢复：如果原作者恢复更新，就需要提交pr，恢复续作者修改的原插件的介绍信息
（逻辑不是很清晰）

[yuyi2439]

我建议是：
续作者在原作者仓库提交pr一段时间(比如一个月)后，原作者未回复，续作者就可以在插件仓库提交pr，将原作修改为Inactive状态，是否符合修改标准需要插件仓库管理员确认

[AnzhiZhang]

3. 若作者不再维护或长期未回复，可自行创建仓库或在社区创建，继续维护插件，原插件从插件库下架或archive

Inactive 如何定义？人工确定吗？

比如作者已经把仓库archive，或发issue询问数周或数月无更新，建立标准即可

[AnzhiZhang]

关于archive插件的恢复：如果原作者恢复更新，就需要提交pr，恢复续作者修改的原插件的介绍信息 （逻辑不是很清晰）

如果恢复更新，我认为应该同理视为新的类似插件，也就是需要考虑被覆盖的插件的更新情况和合作情况

[alex3236]

这么做有一个问题：假设我希望某插件添加一个功能，且该功能需求很广，但插件库已有插件的作者拒绝加入此功能，或因为各种原因无法加入该功能。这时我却不能向插件库加入新插件，因为原有插件依然活跃。

[AnzhiZhang]

这么做有一个问题：假设我希望某插件添加一个功能，且该功能需求很广，但插件库已有插件的作者拒绝加入此功能，或因为各种原因无法加入该功能。这时我却不能向插件库加入新插件，因为原有插件依然活跃。

这是上文提到的作者拒绝合作的情况

[yuyi2439]

关于archive插件的恢复：如果原作者恢复更新，就需要提交pr，恢复续作者修改的原插件的介绍信息 （逻辑不是很清晰）

如果恢复更新，我认为应该同理视为新的类似插件，也就是需要考虑被覆盖的插件的更新情况和合作情况

你的意思是不是原插件处于archive状态较长时间（比如说半年），就应该删除，并且允许续作使用该名称。
然后原插件恢复更新就相当于是这个的第1和3点

[Aimerny]

此处的“名称”我理解不同于插件的id。插件的id应当是唯一的，不论是否被续作者替代。否则在用户视角里同样的插件id得到了更新却可能会出现不完全一致甚至冲突的功能。

[alex3236]

此处的“名称”我理解不同于插件的id。插件的id应当是唯一的，不论是否被续作者替代。否则在用户视角里同样的插件id得到了更新却可能会出现不完全一致甚至冲突的功能。

这时候MCDR没有namespace的坏处就体现出来了（

[AnzhiZhang]

关于archive插件的恢复：如果原作者恢复更新，就需要提交pr，恢复续作者修改的原插件的介绍信息 （逻辑不是很清晰）

如果恢复更新，我认为应该同理视为新的类似插件，也就是需要考虑被覆盖的插件的更新情况和合作情况

你的意思是不是原插件处于archive状态较长时间（比如说半年），就应该删除，并且允许续作使用该名称。 然后原插件恢复更新就相当于是这个的第1和3点

如果插件 A 因为任何原因被插件 B 替代，恢复更新时视为插件 A 想替代插件 B，参照以上三点处理