正如@baradhili在此评论中提到的那样,我们目前有很多未解决的问题。
虽然我确认这是一个不愉快的情况,给开发人员和可能感兴趣的人带来(太大)压力,但我认为这也是一个有用的信息来源,它是 PartKeepr 中无功能和缺失的信息来源。 我不得不承认,并非所有这些问题都是高度优先的,而且有不少问题可能是无效的。
首先,我想创建一个单独的线程来讨论这个问题,而不是在这里劫持任何其他问题。
为了解决整个情况,我建议不要关闭悬空问题。
相反,我建议使用 github 内部功能进行项目管理来对问题进行分类和组织。 这里有一些想法,但有待讨论:
如果项目再次开始在代码库上积极工作,我们可以想到一种陈旧的机器人。 但我认为,只要我们“离线”,就不应该这样做。
可能有一些未解决的问题,确实需要关闭。 在这里,如果问题仍然感兴趣,则警告用户一次并仅关闭那些感兴趣的用户可能会很有用
所以基本上我们创建了一个事实上的“积压”......
@Drachenkaetzchen您是否愿意将我们中的几个人添加到项目中,以便我们可以为问题带来一些秩序?
所以基本上我们创建了一个事实上的“积压”......
有点。 但是,是的,这是基本思想。
@Drachenkaetzchen您是否愿意将我们中的几个人添加到项目中,以便我们可以为问题带来一些秩序?
如果需要,我愿意在这里提供帮助。
大家好,这是一个非常好的主意,我们也在 IRC 上进行了讨论。
我最近获得了 github 的访问权,我将看看添加更多的人来帮助组织方面来管理问题,并感谢您提供的帮助。
(如果由于时间限制我忘记了不要害羞给我戳)
好的@christianlupus我已将您添加为此存储库的分类成员。
@baradhili你也有兴趣帮忙解决这个问题吗?
这里描述了这个功能: https :
当然,最终我们还会添加更多具有代码访问权限的人员。 现在让我们试着把注意力集中在组织问题上。
@dromer是的,请
@dromer感谢您的添加。
第一个建议是添加标签needs-triage
并设置规则以将每个新问题和 PR 放入此标签。
原因:记者认为需要/将要进行分类。 此外,我们可以(稍后)对此类问题进行排序。 也许我们应该考虑把每一个问题都放在这个标签下,看看已经做了什么,需要注意什么。
另外:我还建议使用以下标签:
meta
:用于与代码本身无关但与 repo、wiki、编程标准等相关的问题help-requested
:用于表示问题在设置、使用等过程中寻求帮助。这可能比作为问题保存在 github 上更好地推送到论坛。听起来不错.. 虽然我建议我们不要把所有东西都放在needs-triage
因为我们只会回到现在的位置:).. 我也建议backlog
, next-release
和roadmap
一旦我们得到审查
当我现在开始对一些问题进行分类时,我发现很难给它们贴上标签,除非它们被明确定义(至少是其中的一部分)。
@christianlupus你想如何协调分类? 我在 UTC+8
@christianlupus看起来我们可能需要另一个标签“移动到维基”
@christianlupus你想如何协调分类? 我在 UTC+8
@baradhili我在 UTC+1(柏林)。
我在一些问题上给出了一些标签和适用时的里程碑。 不过,我现在有时间开始工作了。 所以我现在暂停一下。
您对协调有什么好的建议吗? 早上一个人晚上一个人避免碰撞? 你最喜欢在什么时间工作?
由于我不知道您居住在哪个城市,我从指定的时区中随机选取了一个:在这里您可以快速了解如何管理时移。 你可能想收养你的城市。
@christianlupus看起来我们可能需要另一个标签“移动到维基”
是的,似乎是这样。
@christianlupus我目前正在处理bug
标签的旧问题。我想我可以在早上 8 点或 9 点左右花一个小时...我使用同一网站的英文版 - 我'我在珀斯 - 我们可能想用某种标签标记复杂的问题,以便其他人可以查看并发表意见..
@dromer,如果我们给你一个新标签列表,你可以添加它们吗?
哦,这是我需要做的事情吗?
让我知道,我会考虑添加更多。
@christianlupus我目前正在处理
bug
标签的旧问题。我想我可以在早上 8 点或 9 点左右花一个小时...我使用同一网站的英文版 - 我我在珀斯——
好的,这完全取决于您。 感谢您在这里提供帮助。 我现在正在处理未标记的问题,所以我们没有发生冲突。
我们可能想用某种标签标记复杂的问题,以便其他人可以查看并发表意见。
是的,我认为这是个好主意。 complex-triage
怎么样?
哦,这是我需要做的事情吗?
让我知道,我会考虑添加更多。
我们只能在问题上附加标签和里程碑。 但是我们不能将新标签添加到有效标签列表中。 所以,是的,我们会要求您添加相关标签。
@baradhili所以我们没有这个新标签列表(请纠正我):
meta
help-requested
move-to-wiki
complex-triage
关于及时标签( backlog
, roadmap
, next-release
)我认为这最好通过里程碑来捕捉,你不觉得吗? 此外,这必须与向 repo 提供代码的任何人协调。
一旦出现对新标签的需求,我将更新此评论。 可以吗? 如果是,请随时询问dromer。
@dromer
我们可以设置以下标签吗?
meta
help-requested
move-to-wiki
complex-triage
security-issue
谢谢
@baradhili我尝试将标签组织在一个MD 文件中。 我将您添加为协作者,以便您可以编辑文件。
就我写的定义而言,你对它们还满意吗?
都好!
2020 年 1 月 14 日星期二 19:36,Christian [email protected]写道:
@baradhili https://github.com/baradhili我试图组织标签
在 MD 文件中
https://github.com/christianlupus/Test-PK-Pages/wiki/Issue-Labels
少量。 我将您添加为协作者,以便您可以编辑文件。就我写的定义而言,你对它们还满意吗?
—
你收到这个是因为你被提到了。
直接回复此邮件,在 GitHub 上查看
https://github.com/partkeepr/PartKeepr/issues/1066?email_source=notifications&email_token=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4JJYQ#issuecomment-57413
或退订
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANCNFSM4KF76JRA
.
--
布雷特·沃森
导演
IT 临时管理有限公司 T/A TICM
手机:+61 (0)41 33 03 840
电子邮件:[email protected]
“此电子邮件传输的内容仅供指定的
收件人,可能是保密的,可能是特权或其他
保护公众利益不被披露。 使用、再生、
通过以下方式披露或分发此电子邮件传输的内容
禁止指定收件人以外的任何人。 如果你不是
指定收件人请立即通知发件人。”
build system
显然与 ci/cd 有关(请参阅我的 2 个 PR),所以我会保留它。
我将添加您的列表@baradhili ,希望你们至少可以继续前进。
目前,我认为拥有“太多”标签比拥有“太少”标签是可以的。 我们总是可以删除/忽略某些标签。
您想要与它们关联的任何特定颜色? :)
好吧,太晚了,我现在使用默认颜色:D
@dromer我们可以为 1.5.0
@christianlupus我将使用1 - Ready
来处理出现/声称已修复但需要测试的东西
回想起来@dromer ..我意识到我可以用Must Have
处理看起来需要“很快”完成的事情
@christianlupus完成了Bug
.. 现在正在处理没有里程碑的旧问题
只要问题可以关闭,我就会删除Will be closed soon!
和Feedback Needed
类的标签。 这对我们常见的工作流程来说可以吗?
@dromer我可以多加一个标签.. low-hanging
吗? 我不时看到应该很容易解决的问题
@christianlupus是的..我应该回去检查我是否已经做到了
如果您使用标签good first issue
显然 github 提供了一些自动化的“钩子”:
为新贡献者标记问题和拉取请求
现在,GitHub 将帮助潜在的首次贡献者发现标有
good first issue
那我应该这样称呼它吗?
这个标签的问题将出现在其他一些应该鼓励人们参与的概述中。
为我工作! :)
@baradhili我刚刚解决了未标记的问题。 老实说,我今天不会继续,这已经足够了。 不过,我想和你一起安排接下来的步骤。 期待您的回复。
@christianlupus是的.. 我发现我每天可以维持大约 20/25 个问题.. 之后我的大脑被炸了......
今天早上我会去跑步。。
@dromer下一步我们可能不得不开始考虑优先级.. 最重要的是.. 分配给开发人员.. 我们有开发人员吗?
@baradhili我刚刚向您的 ticm 域发送了一封电子邮件。 你能查一下你的账户吗?
我们有开发人员吗?
呃......如果我们这样做了,我们就不会有这个积压:)
我认为你们的进展比目前“允许”的项目要快一些,这是一件好事,因为组织积压工作会堵塞事情,所以希望优先级能够帮助那些愿意做出贡献的人集中注意力。 (找到他们,或者让他们找到我们,当然是一个不同的挑战)
好的,伙计们..我们现在有一个问题列表,其中所有问题都分配给了一个里程碑,并且已经关闭了很多
我认为我们现在的重点是让某人发展 :) 遗憾的是,我在 ExtJS 和 Symfony 周围有 NFI,所以无能为力......
选项
此外,您应该确保不要在不与他接触的情况下移除其辛勤工作而将其踢到牙齿上。 这发生在我的打印功能上,从那时起,我只是从旁边观察这里发生的事情。 我还坚持了一个在新版本中没用的软件,因为没有再添加这样的功能。
应该有一个清晰的结构来处理这些事情,以及架构决策或什么是做某事的好习惯。 该项目本身结构清晰,而且不是 php 专家(但其他语言的编程专家)的人也可以在使用的框架和结构的一些帮助下轻松实现事物。
@Boldie嗨 Sven,如果您的作品在没有通知的情况下被删除,我们尤其是开发人员_
顺便说一句 - 我假设您的打印功能可以批量打印? 需要什么才能让它再次工作?
应该有一个清晰的结构来处理这些事情,以及架构决策或什么是做某事的好习惯。
这大部分是正确的,但因为该项目主要是在一个人的项目中管理的。 无需定义与社区互动的规则。 当我们开始将项目的重量分摊给多人时,定义如何进行的规则可能是有益的。
该项目本身结构清晰,而且不是 php 专家(但其他语言的编程专家)的人也可以在使用的框架和结构的一些帮助下轻松实现事物。
我假设您自己是一名程序员,能够权威地发表这样的声明。 我并不是要冒犯任何人,但与此同时,我认为在代码上开发你的脚更难。
我试过了,但很难。 这些库已经过时了,同时关于这些旧代码的文档也很少见。 此外,项目的文档(例如#635)并不完整。
我不是在这里欺负人,但我想指出当前软件的一些关键问题。 由于当时最初的开发人员大多无法联系到,我们需要至少知道部分代码的人才能让事情重回正轨。 我希望“老贡献者”能够在这里提供帮助。 有一些错误需要删除,但主要问题是软件不再维护和维护依赖关系。 我们需要解决主要问题,否则项目将失败。
所以我问你:你有没有处理过代码,你有相关依赖的经验吗?
顺便说一句 - 我假设您的打印功能可以批量打印? 需要什么才能让它再次工作?
@Boldie ,我建议您打开一个新问题来跟踪缺失的功能。 在某些时候,这里的这个问题将被归档。 因此,大多数人都会忘记您要求恢复打印功能的请求。
顺便说一句 - 我假设您的打印功能可以批量打印? 需要什么才能让它再次工作?
它由两部分组成:
- 将 StorageLocations / Parts 批量打印为 pdf
- 打印单个部件(用于标签)
第一个是高度集成的,但也增加了一些有问题的依赖项。 第二个可能会在今天使用 REST API 再次更好地实现。 它仍然在这 200 个未解决的问题之一中被跟踪 :)
我只是看了一下代码:我对这些东西的实际工作方式有一些问题。 该框架似乎使用了一种难以遵循的松散耦合。 也许使用这个框架的专家会说一些不同的东西(大部分时间,我接触 C++,有时接触 python 和 django)。 我只记得当我第一次实现时,这也很难弄清楚如何添加一些东西。 在我看来,问题在于将这个项目从一个或多或少的单人表演引导到一个社区驱动的项目。 不幸的是,我不是帮助解决依赖性问题的人,但我同意,这必须是首先要解决的问题,以减少技术部门。
为了简化开发,我建议设置一种无需重复工作即可轻松开始开发的环境。 在我的公司,我们已经设置了一个包含这些东西的 docker 容器,以及一个运行测试/添加演示数据的脚本,......以使开发开始变得容易。
有没有办法联系社区? 我想大多数用户都没有意识到我们需要一些帮助,否则该项目将越来越过时,并且在某些时候不再可用。 是否可以在主页上发表声明? 由于有大部分下载,因此具有适当知识的人不了解情况和这里的存储库。
@Boldie好主意! @dromer @Drachenkaetzchen有人可以访问主页吗?
@christianlupus这里或里程碑视图中是否有一个列表,接下来需要完成哪些工作? 我认为第一件事就是升级到 Symhony4 #1083 ?
@Boldie是的,已经针对优先事项做了一些工作。 看到这个列表:
https://github.com/partkeepr/PartKeepr/issues?q=is%3Aopen+is%3Aissue+label%3A%22Must+Have%22
升级 symfony 和其他依赖项是目前最大和最重要的一项。
(虽然我认为“好的第一个问题”标签适用于新手,而不是“需要先完成”的名称)
有没有办法联系社区?
我们在 irc.freenode.net 上的 #partkeepr irc 频道中有许多用户
还有谷歌群组(公共和私人群组),但我认为问题跟踪器 + IRC 是目前与人们谈论 PartKeepr 的最佳选择(就活动而言)。
此外,您应该确保不要在不与他接触的情况下移除其辛勤工作而将其踢到牙齿上。 这发生在我的打印功能上,从那时起,我只是从旁边观察这里发生的事情。 我还坚持了一个在新版本中没用的软件,因为没有再添加这样的功能。
我必须删除该功能的原因记录在这里: https :
如果您觉得自己被踢到了牙齿,我很抱歉,但那是当时的情况。
另外,我他妈的每天大部分时间都在写这个软件。 请他妈的理解,如果我必须删除代码以制作更新的版本,那么为了他妈的就这样吧。 您可以创建另一个 PR 以使其与新版本兼容
是的,我现在很生气。 我花了这么多年的时间免费编写代码,完成了大部分工作,做了大量的支持工作,试图创业,而我从数百小时甚至数千小时的无偿工作中得到的只是这些。
如果不是我的责任感,我会在 2 年前关闭网站和其他一切。
这些时间我几乎没有足够的钱来维持一个月,有几种疾病我不太可能很快康复,我仍然试图以某种方式让这个项目保持活力,尽管我几乎无法做到这一点。
另外,我他妈的每天大部分时间都在写这个软件。 请他妈的理解,如果我必须删除代码以制作更新的版本,那么为了他妈的就这样吧。 您可以创建另一个 PR 以使其与新版本兼容
是的,我现在很生气。 我花了这么多年的时间免费编写代码,完成了大部分工作,做了大量的支持工作,试图创业,而我从数百小时甚至数千小时的无偿工作中得到的只是这些。
如果不是我的责任感,我会在 2 年前关闭网站和其他一切。
这些时间我几乎没有足够的钱来维持一个月,有几种疾病我不太可能很快康复,我仍然试图以某种方式让这个项目保持活力,尽管我几乎无法做到这一点。
我知道你的情况很严重,包括社区在内的这个项目对你的情况有贡献。 我也尊重你的工作,我也认为这个项目(尤其是与其他项目相比)有一个很好的结构,否则我不会想我能做些什么来振兴这个项目,以及如何让一个开发团队做好准备必要的工作。
我现在不想热身,它不会帮助我们继续与 Partkeepr 走得更远。
从我的日常工作中,我知道有时很难处理来自其他人的代码,尤其是在无法联系到该人的情况下(为了将来,如果有必要,每个人都可以通过 git 提交的电子邮件地址或使用域与我联系使用我的主页与我联系)。 每个人在编写代码时都有自己的笔迹。 在我看来,它是一种编写代码的手艺。 我也有很多复杂性方面的经验,如果要升级一个库或一堆依赖项,那么通过它是多么困难。 在我的带薪工作中,我和一个团队一起做了几个月。
所以现在我们再次面临这个挑战,我们必须想办法与社区一起做这件事。 这比在付费环境中更具挑战性,人们会说:我们会这样做。
我查看了代码,因为我上次做了一些事情,它改变了很多(有人在这里投入了大量的工作!!:)。 所以我不得不再次深入研究代码并开始工作。 但为此,我们需要密切的沟通和路线图,下一步该做什么。 我认为与其他事情相比,恢复打印功能的优先级很低,我或其他人可以稍后再做。 对我来说,更值得不要在未来的下一次操作系统升级中丢失我的数据,因为这也意味着要迁移到其他东西(我不知道这会是什么),这需要很长时间的工作在我的业余时间填充数据库。
谢谢@Boldie
@christianlupus @dromer我想我们可以关闭这个了,因为事情又开始了......!
还有一点要讨论:由于 #1091 中的更改,所有新问题都将附加一些标签。 我们是否想要一个指标表明这里没有进行人工审查?
除此之外,我现在可以关闭此问题。
我们所做的与人工审查有何不同? :)
@baradhili这正是我们最近所做的。 我的意思是:由于命名的 PR 被接受,任何新问题都将根据所选问题的类型将错误、功能请求或需要帮助的预设作为标签。
这意味着新问题(尚未通过我们最近所做的手动分类)不会显示为没有附加标签。 因此,GitHub 中没有简单的过滤器来选择那些尚未人工分类的问题。
简而言之:我们是否想要一个need-triage
或类似的来表示。
我们可以在github的模板系统下自动添加needs-triage
标签吗?
是的,这是在模板文件中添加标签并更改一行的问题。 这应该足够了。
我刚刚打开了关于问题模板系统的#1097。 如果不需要needs-triage
标签,我建议删除单个提交。
现在关闭这个
最有用的评论
为我工作! :)