开源改变世界

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960

推推 grbl 3年前 (2023-01-31) 233次浏览
打开
silopolis 打开了这个问题 2022 年 8 月 23 日 · 14条评论
打开

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki)#1960

silopolis 打开了这个问题 2022 年 8 月 23 日 · 14条评论

注释

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
贡献者

大家好,

从家庭假期回来,在工作问题拖延了太多周之后,即使我尽力跟踪同时完成的所有伟大工作,我希望我们有一个更有条理的组织来更容易地:

  • 比简单的、未标记的问题列表更清楚地了解 LinuxCNC 项目状态
  • 使用项目和里程碑来管理和跟踪我们的“计划”(Debian 集成、po4a 迁移、2.9 发布…)
  • 支持并记录我们长期运行的讨论(今天分散在许多问题中)并准备会议
  • 使用 Wiki 支持以上所有文档和更结构化的信息收集

对于那些想一睹这一切的人,你可以在这里查看我的游乐场(如果你也想玩,请索取权利):

我相信这些工具可以在很多方面对我们的项目有所帮助。我知道管理所有这些将是额外的工作,但由于我自己觉得需要这些功能,所以我愿意为社区设置它们。

我的计划是首先使用这些功能来规划和管理他们自己的部署:

  • 将创建一个项目来管理此部署
  • 将创建一个里程碑来跟踪进度
  • 将创建关于以下方面的开创性讨论:
    • 标签分类法和用法
    • 项目和里程碑的使用
    • 讨论用法
    • GH wiki 使用,与当前 wiki 或对比
  • 一旦就每件事达成某种共识:
    • 它将在其自己的 Wiki 页面中进行总结
      关于 wiki 页面,每个页面都可以链接
    • 将逐步创建由此产生的标签、项目、里程碑、问题、讨论和 Wiki 页面

期待各位小伙伴的阅读

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
合作者
彼得赖因霍尔特森 评论了 2022 年 8 月 23 日 通过电子邮件
扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
贡献者作者
筒仓 评论了 2022 年 8 月 24 日 通过电子邮件
扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
合作者

(来自 #1899的评论)我似乎对里程碑的使用与我的意思不同。

里程碑实际上只是将一堆问题组合在一起以跟踪
进度。截止日期甚至不是强制性的。

当我说里程碑时,我指的是日期。
没有日期的里程碑不是很有效。

你们谈论的远远超过我们需要开始的事情。没关系,前瞻性思维是好的。但是:
我们仍然没有选择 2.9 的官方日期(除了“几周内”和“今年”)
我们甚至还没有一个 2.9 分支可以实际工作。
我们似乎认为在开发分支中稳定我们的开发分支以进行发布是个好主意。
我们甚至没有有效地使用邮件列表,使用 github 是一个更高的标准。

也许我们应该讨论项目需要什么来发展开发人员和用户。
一些政策讨论——比如合并已发布的分支是愚蠢的,也是一个障碍。

有些人如果使用 github 可以促进这一点,那么当然,但电子邮件也可以。

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
贡献者作者
筒仓 评论了 2022 年 8 月 26 日 通过电子邮件
扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
合作者

里程碑 – 足够公平的里程碑可以两种方式使用,并且两者都很有用。在我看来,为 say 版本设置日期确实是最重要的事情——这样不同时区和空闲时间的人就可以同步。
但是,是的,没有日期的里程碑确实表明了方向,这也很好。

Debian 时间表 – 我不知道 Debian 的标准/目标(可能是写的好东西) – 原则上它似乎是一个很好的目标,也许有助于设定截止日期。Hopeful 有助于让用户和开发人员感兴趣。我认为我们需要让我们的房子井井有条,否则可能会变得太难做所有需要做的事情,和我们现有的人一起。
恕我直言,我们现在应该创建 2.9 候选版本 – 有一些工作可以完成,它发出一个信号,并允许 master 有点不稳定,同时仍然有一个可用的(对于勇敢的)分支和新功能。
我就此发送了一封电子邮件,但实际上没有得到任何回复。

合并分支——这显然是 git 项目中常见的事情。在我们的项目 AFAICT 上这样做是一件愚蠢的事情。我问过我们为什么要这样做,但从来没有得到好的答案。总是“因为每个人都在做”或者有人解释了合并的过程,我当然已经知道了。

  • 冲突,为开发人员合并设置高标准 – 例如,我对翻译了解多少?所以要么我不合并让别人受苦,要么我猜应该做什么,而人们猜测会导致问题。由于合并错误,我必须多次修复错误。
    樱桃挑选或为每个分支准备单独的补丁很容易,如果有冲突(樱桃挑选)代码是我的,所以我知道如何修复它。
    这只是 Andy 想要向后移植工作,而翻译人员担心浪费工作来解决冲突。如果你不合并,一切都会消失。
    正如我所说,我从来没有得到一个很好的答案,为什么向上合并是值得的。

我短暂地参加了 Zoom 会议——音频对我来说太糟糕了,没用了。我试着说了几次,但似乎都失败了。我只能听到一半的内容。
面对面的会议对于一些需要快速回答的事情来说很好,但是对于一个国际团体来说,他们很难包括每个人并且没有总结每个人都会错过(IRC 是相似的但至少它可以通过阅读后者)
还有链接在哪里发布以便有人可以找到它?

电子邮件很好,因为进入门槛低,您可以随时回复,并且可以通过线程跟踪对话 – 但它肯定很慢。
我想每个人都有自己喜欢的形式。

感谢您的互动并让我解释我的想法,
我会尽量不变成“否定者”:)

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
贡献者

你们谈论的远远超过我们需要开始的事情。没关系,前瞻性思维是好的。但是:我们仍然没有选择 2.9 的官方日期(除了“几周内”和“今年”)我们甚至还没有一个 2.9 分支可以实际工作。我们似乎认为在开发分支中稳定我们的开发分支以进行发布是个好主意。我们甚至没有有效地使用邮件列表,使用 github 是一个更高的标准。

@c-morley– 请每下午联系@hansu谁是我们下一次视频会议的主持人 根据您的喜好制定会议议程。或许你应该是策划接下来的会议的人。

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
成员

@c-morley– 请每下午联系@hansu谁是我们下一次视频会议的主持人 根据您的喜好制定会议议程。或许你应该是策划接下来的会议的人。

您可以只编辑https://docs.google.com/document/d/1aWMxBY8IbCYXFLFvjgqUXZ09inZp5u0r-pZcjeb2bWk/edit
如果您没有访问权限,请联系@smoe.

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
合作者

我真的不太喜欢视频会议。我不明白为什么我们需要视频会议来讨论。

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
合作者
彼得赖因霍尔特森 评论了 2022 年 8 月 29 日 通过电子邮件
扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
合作者

我看不出每个月 2 小时的带宽比一个月的电子邮件/github 对话更多。
我并不是说没有视频会议的空间——我是说我们可以在会议召开时已经弄清楚事情或至少针对少数决定。

我们是一个国际团体,找到适合每个人的时间并有足够的时间充分讨论事情几​​乎是不可能的。

我真的不明白为什么人们不想讨论事情。为了让项目/社区变得更好,我们需要相互交流和挑战。即使我们有时是错的。
我们互动得越多越好 – 等待我们可以在屏幕上看到对方就没那么重要了。

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
成员

我真的不明白为什么人们不想讨论事情。

我不认为人们不想讨论事情。但在视频会议中,你总是会得到答案,有时在问题或通过邮件列表的邮件中提出的问题并非如此。

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
合作者

雅那是我不明白的部分。例如,如果您关心发布 2.9,为什么不在电子邮件中发表意见。或者我们应该关闭邮件列表。

无论如何,感谢您试图帮助我理解。

扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
合作者
phillc54 评论了 2022 年 8 月 29 日 通过电子邮件
扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960
贡献者
下雪人540 评论了 2022 年 8 月 31 日  

鉴于这个问题是 8 天前创建的,我现在才看到它,我也不认为 Git 是一种有效的沟通方式。

虽然我认为自己对这个项目非常感兴趣和积极,但我也不得不说我对参加视频会议没什么兴趣。更不用说最近几次发生在我日常工作期间的事实。我也更喜欢电子邮件对话。我可能并不总是参与,但我总是阅读它们,这有助于我了解情况。

我担心有一个额外的新地方来检查事情,并跟上正在发生的事情。在论坛、git 和电子邮件之间,其中之一肯定适用于所有人。

我还担心做出决定仅仅是因为参加视频会议的人同意了,而没有那些不能参加的人的意见。或者更好的说法是,我担心某人的意见会因为无法参加视频会议而被贬低。

免费注册 在 GitHub 上加入此对话。已有帐户? 登录评论
标签
还没有
项目

还没有

发展

没有分支机构或拉取请求

7人参加
扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960扩展 GitHub 功能使用(即标签、项目、里程碑、讨论、Wiki) #1960

喜欢 (0)