Partkeepr: メタ：未解決の問題が多すぎます

つまり、基本的には事実上の「バックログ」を作成します...
@Drachenkaetzchenは、私たちが問題に何らかの秩序をもたらすことができるように、私たちのカップルをプロジェクトに追加することを

つまり、基本的には事実上の「バックログ」を作成します...

ある種。 しかし、はい、これが基本的な考え方です。

@Drachenkaetzchenは、私たちが問題に何らかの秩序をもたらすことができるように、私たちのカップルをプロジェクトに追加することを

必要に応じて、ここでお手伝いさせていただきます。

やあみんな、これは非常に良いアイデアであり、IRCでも私たちによって議論されました。

私は最近githubにアクセスしました。問題を管理するために組織側を支援するためにさらに何人かの人々を追加することを検討し、これを支援するためのあなたの申し出に感謝します。
（時間の制約のために、私がそれについて突くのを恥ずかしがらずに忘れないでください）

OK @ christianlupusこのリポジトリにトリアージメンバーとしてあなたを追加しました。
@baradhiliあなたもこれを手伝うことに興味がありますか？

このための機能について説明します： https ：

もちろん、最終的には、コードにアクセスできる人も追加する予定です。 とりあえず、問題の整理に焦点を当ててみましょう。

@dromerはいお願いします

@dromer追加していただきありがとうございます。

最初の提案は、ラベルneeds-triageを追加し、すべての新しい問題とPRをこのラベルに入れるルールを設定することです。
理由：レポーターは、トリアージが必要である/実行される予定であると認識しています。 さらに、そのような問題を（後で）並べ替えることができます。 おそらく、すでに行われていることと注意が必要なことを確認するために、すべての問題をこのラベルの下に置くことを検討する必要があります。

さらに、次のラベルもお勧めします。

• meta ：コード自体ではなく、レポ、ウィキ、プログラミング標準などに関連する問題に使用されます
• help-requested ：セットアップ、使用などの際に問題がヘルプを求めていることを示すために使用されます。これは、ここgithubに問題として保持されるよりも、フォーラムにプッシュする方がよい場合があります。

良さそうです.. needs-triage下にすべてを詰め込まないことをお勧めしますが、私たちは今いる場所にたどり着くだけなので:) .. backlog 、 next-releaseもお勧めします検討中のものを入手したら、 roadmap

今、いくつかの問題を分類し始めたとき、それらが明確に定義されていない限り（少なくともそれらの一部について）、それらにラベルを付けるのは難しいことに気づきました。

@christianlupusトリアージをどのように調整しますか？ 私はUTC + 8にいます

@christianlupus別のタグ「move-to-wiki」が必要になる可能性があるようです

@christianlupusトリアージをどのように調整しますか？ 私はUTC + 8にいます

@baradhili私はUTC + 1（ベルリン）にいます。
私はいくつかの問題にいくつかのラベルと該当する場合のマイルストーンを与えていました。 しかし、今は仕事に取り掛かる時間があります。 だから私は今のところ一時停止します。

調整について何か良い提案はありますか？ 衝突を避けるために朝に一人、夕方に一人？ それに取り組むのにあなたが好む時間は何ですか？

あなたが住んでいる都市がわからないので、名前の付いたタイムゾーンからランダムに1つを選びました。ここでは、タイムシフトを管理するための簡単な概要を取得できます。 あなたはあなたの街に採用したいかもしれません。

@christianlupus別のタグ「move-to-wiki」が必要になる可能性があるようです

うん、そうだね。

@christianlupus現在、 bugタグの古い問題に取り組んでいます。私の時間は、午前8時または午前9時頃に1時間入れることができると思います...同じサイトの英語版を使用しています-私はパースにいる-他の人が見て意見を述べることができるように、ある種のタグで複雑な問題にフラグを立てたいと思うでしょう。

@dromer新しいタグのリストを提供した場合、それらを追加できますか？

ああ、これは私がしなければならないことですか？

私に知らせてください、そして私はさらにいくつかを追加することを検討します。

@christianlupus現在、 bugタグの古い問題に取り組んでいます。私の時間は、午前8時または午前9時頃に1時間入れることができると思います...同じサイトの英語版を使用しています-私はパースにいる-

OK、これは完全にあなた次第です。 ここで助けてくれてありがとう。 私は今のところラベルのない問題に取り組んでいるので、衝突していません。

ある種のタグで複雑な問題にフラグを立てて、他の人が見て意見を述べることができるようにしたいでしょう。

はい、これは良い考えだと思います。 complex-triageどうですか？

ああ、これは私がしなければならないことですか？

私に知らせてください、そして私はさらにいくつかを追加することを検討します。

ラベルとマイルストーンのみを問題に添付できます。 ただし、有効なラベルのリストに新しいラベルを追加することはできません。 したがって、はい、関連するラベルを追加するようにお願いします。

@baradhiliだから、私たちはこの新しいラベルのリストを持っていません（私を訂正してください）：

• meta
• help-requested
• move-to-wiki
• complex-triage

タイムリーなラベルについて（ backlog 、 roadmap 、 next-release ）これはマイルストーンによってよりよく捕らえられると思いますね。 また、これは、リポジトリにコードを提供する人と調整する必要があります。

新しいラベルの必要性が出てきたらすぐにこのコメントを更新します。 それで大丈夫ですか？ もしそうなら、それについてドロマーに気軽に聞いてください。

@dromer
次のラベルを設定できますか？

• meta
• help-requested
• move-to-wiki
• complex-triage
• security-issue

ありがとう

@baradhiliMDファイルのラベルを少し整理してみました。 ファイルを編集できるように、共同編集者としてあなたを追加しました。

私が書いた限り、定義は大丈夫ですか？

よかった！ドキュメンテーション！

午後7時36分で火、2020年1月14日には、キリスト教の[email protected]は書きました：

@baradhilihttps ：//github.com/baradhiliラベルを整理しようとしました
MDファイル内
https://github.com/christianlupus/Test-PK-Pages/wiki/Issue-Labels a
少し。 ファイルを編集できるように、共同編集者としてあなたを追加しました。

私が書いた限り、定義は大丈夫ですか？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/partkeepr/PartKeepr/issues/1066?email_source=notifications&email_token=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANCNFSM4KF76JRA
。

-
ブレットワトソン
監督
IT Interim Management Pty Ltd T / A TICM
暴徒：+61（0）41 33 03 840
Eメール：[email protected]
「この電子メール送信の内容は、指定された人のみを対象としています。
受信者は、機密情報である可能性があり、特権またはその他の方法である可能性があります
公益のための開示から保護されています。 使用、複製、
この電子メール送信の内容の開示または配布
指定された受信者以外の人は禁止されています。 そうでない場合
指定された受信者は、すぐに送信者に通知してください。」

build system明らかにci / cdと関係があるので（私の2つのPRを参照）、それを維持します。

私はあなたのリストを@baradhiliに追加します、そしてうまくいけばあなたたちは少なくとも前進することができます。
今のところ、「少なすぎる」よりも「多すぎる」ラベルを使用しても問題ないと思います。 特定のラベルはいつでも削除/無視できます。

それらに関連付けたい特定の色はありますか？ :)

遅すぎます、今のところデフォルトの色で行きました：D

@dromer 1.5.0のマイルストーンはありますか？

@christianlupus修正されたように見える/修正されたと主張されているものに1 - Readyを使用しますが、テストが必要です

振り返ってみるとMust Have 「すぐに」実行する必要があるように見えることを処理できることに気づきました
@christianlupusはBugました..マイルストーンのない古い問題に取り組んでいます

問題が解決したらすぐに、 Will be closed soon!やFeedback Neededなどのラベルを削除します。 これは私たちの一般的なワークフローで大丈夫ですか？

@dromerタグを1つ追加できますか.. low-hanging ？ 簡単に修正できるはずの問題が時々見られます

@christianlupusはい..そして私は戻ってそれをしたことを確認する必要があります

代わりにタグgood first issueを使用すると、githubは自動化された「フック」を提供するようです。

問題にラベルを付け、新しい寄稿者のリクエストをプルします

これで、GitHubは、潜在的な初めての寄稿者がgood first issueというラベルの付いた問題を発見するのに役立ちます

それで、代わりにそれを呼ぼうか？
このタグの問題は、人々の参加を促すと思われる他のいくつかの概要に表示されます。

https://github.com/partkeepr/PartKeepr/contributeのように

私のために働く！ :)

@baradhili私は今タグなしの問題を解決しました。 正直なところ、今日は先に進みません。これで十分でした。 それにもかかわらず、私はあなたと次のステップを手配したかった。 お返事をお待ちしております。

@christianlupusはい..私は1日あたり約
今朝走ります。

@dromer次のステップでは、おそらく優先順位付けを検討し始める必要があります。そして最も重要なのは、開発者はいますか？

@baradhili私はあなたにあなたのticmドメインにメールを送りました。 アカウントを確認していただけますか？

開発者はいますか？
えーと...もし私たちがそうしたら、このバックログはありません:)

皆さんは現在プロジェクトが「許可している」よりも少し速く動いていると思います。これは、バックログの整理が物事を詰まらせていたので良いことです。 （もちろん、彼らを見つけること、または彼らに私たちを見つけてもらうことは別の挑戦です）

わかりました。これで、すべての問題がマイルストーンに割り当てられ、かなり多くの問題がクローズされた問題リストが作成されました。
今の私たちの焦点は誰かを開発させることだと思います:)悲しいことに私はExtJSとSymfonyの周りにNFIを持っているので仕方がありません...

オプション

1. スポンサーを取得し、guru.comまたはstackexchangeでフリーランサーを使用します
2. 私たちは自分自身を見つけようとします
3. ？

さらに、誰かに連絡せずにそのハードワークを取り除くことによって、誰かを歯で蹴らないようにする必要があります。 これは私の印刷機能に起こりました、そしてそれ以来、私はここで何が起こっているかを傍観者から見ているだけでした。 また、そのような機能が再び追加されなかったため、新しいバージョンでは役に立たないソフトウェアに固執しました。

そのようなことをどのように処理するか、またアーキテクチャ上の決定や、何かを行うための良い習慣は何かを明確に構造化する必要があります。 プロジェクト自体は明確に構造化されており、PHPの専門家ではない人（ただし、他の言語のプログラミングの専門家）も、使用するフレームワークと構造の助けを借りて簡単に実装できます。

@Boldie Hi Sven、あなたの作品が予告なしに削除された場合はお詫びします。最近のプロジェクトでは状況が大きく変化しており、コミュニティの信頼を築くことに非常に熱心です特に開発者_

ところで-私はあなたの印刷機能がバルク印刷を行うと思いますか？ それを再び機能させるために何が必要でしょうか？

そのようなことをどのように処理するか、またアーキテクチャ上の決定や、何かを行うための良い習慣は何かを明確に構造化する必要があります。

これはほとんど正しいですが、プロジェクトはほとんど1人のプロジェクトで管理されていたためです。 コミュニティと対話するためのルールを定義する必要はありませんでした。 プロジェクトの重要性を複数の人に共有し始めると、どのように進めるかについてのルールを定義することが有益かもしれません。

プロジェクト自体は明確に構造化されており、PHPの専門家ではない人（ただし、他の言語のプログラミングの専門家）も、使用するフレームワークと構造の助けを借りて簡単に実装できます。

私はあなたが権威を持ってそのような声明を出すことができるあなた自身のプログラマーであると思います。 私は誰かを怒らせるつもりはありませんが、それまでの間、コードの開発で足を濡らすのは難しいと思います。

やってみましたが大変でした。 ライブラリは地獄のように時代遅れであり、これらの古いコードに関するドキュメントは当面はまれです。 さらに、プロジェクトのドキュメント（例：＃635）は完全ではありません。
私はこの辺りでいじめをしているわけではありませんが、現在のソフトウェアのいくつかの重大な問題を指摘したいと思います。 当時、元の開発者にはほとんど連絡が取れなかったため、コードの少なくとも一部を知っている人が物事を軌道に戻す必要があります。 「古い貢献者」がここで助けてくれることを願っています。 削除すべきバグがいくつかありますが、主な問題は、ソフトウェアがもはや保守されておらず、依存関係に関して保守可能ではないことです。 主な問題を解決する必要があります。そうしないと、プロジェクトは失敗します。

だから私はあなたに尋ねます：あなたはコードに取り組みましたか、そしてあなたは関連する依存関係の経験がありますか？

ところで-私はあなたの印刷機能がバルク印刷を行うと思いますか？ それを再び機能させるために何が必要でしょうか？

@Boldie 、不足している機能を追跡するために新しい問題を開くことをお勧めします。 ある時点で、この問題はここにアーカイブされます。 その結果、印刷​​機能を元に戻すというあなたの要求は、ほとんどの人に忘れられてしまいます。

ところで-私はあなたの印刷機能がバルク印刷を行うと思いますか？ それを再び機能させるために何が必要でしょうか？
それは2つの部分で構成されています：

• StorageLocations /パーツのPDFへの一括印刷
• 単一パーツの印刷（ラベル用）

最初のものは高度に統合されていましたが、いくつかの問題のある依存関係も追加しています。 2つ目は、今日のRESTAPIを使用してさらに適切に実装される可能性があります。 それはまだこれらの200の未解決の問題の1つで追跡されています:)

コードを見たところです。このようなものが実際にどのように機能しているかについて、いくつか問題があります。 フレームワークは、従うのが難しい一種の緩い結合を使用しているようです。 たぶん、このフレームワークを使用している専門家は何か違うことを言うでしょう（ほとんどの日、私はC ++と連絡を取り、時にはdjangoとPythonを利用しています）。 私が最初の実装を行ったとき、これもいくつかのものを追加する方法を理解するのが難しいことを思い出しました。 私が見ている問題は、このプロジェクトを多かれ少なかれ個展からコミュニティ主導のプロジェクトに導くことです。 残念ながら、私は依存関係の問題を支援するのは間違っていますが、技術的負債を減らすためにこれを最初に解決する必要があることに同意します。

開発を容易にするために、2回の作業をしなくても簡単に開発を開始できるような環境を整えることをお勧めします。 私の会社では、開発を簡単に開始できるように、テストを実行したりデモデータを追加したりするためのDockerコンテナとスクリプトをセットアップしました。

コミュニティに連絡する方法はありますか？ ほとんどのユーザーは、ここで助けが必要であることを認識していないと思います。そうしないと、プロジェクトはますます時代遅れになり、いつかは使用できなくなります。 ホームページに声明を出すことはできますか？ ほとんどのダウンロードがあるので、適切な知識を持っている人は状況とこのリポジトリをここに認識していません。

@Boldieいいアイデア！ @dromer @Drachenkaetzchen誰かがメインのWebページにアクセスできますか？

@christianlupusここまたはマイルストーンビューに、次に実行する必要のある作業のリストがありますか？ 最初に行うことの1つは、Symhony4＃1083にアップグレードすることだと思いますか？

@Boldieはい、優先順位の問題に対して行われた作業があります。このリストを参照してください：

https://github.com/partkeepr/PartKeepr/issues?q=is%3Aopen+is%3Aissue+label%3A%22Must+Have%22

symfonyやその他の依存関係のアップグレードは、現時点で最大かつ最も重要なものです。
（「良い最初の問題」タグは、「最初に行う必要がある」という指定ではなく、新規参入者を対象としていると思います）

コミュニティに連絡する方法はありますか？
irc.freenode.netの#partkeeprircチャネルに多数のユーザーがいます
グーグルグループ（パブリックグループとプライベートグループ）もありますが、問題追跡システム+ IRCは、現時点で（アクティビティの観点から）PartKeeprについて人々と話すための最善の策だと思います。

さらに、誰かに連絡せずにそのハードワークを取り除くことによって、誰かを歯で蹴らないようにする必要があります。 これは私の印刷機能に起こりました、そしてそれ以来、私はここで何が起こっているかを傍観者から見ているだけでした。 また、そのような機能が再び追加されなかったため、新しいバージョンでは役に立たないソフトウェアに固執しました。

機能を削除しなければならなかった理由はここに文書化されています： https ：

歯を食いしばられたと感じたらごめんなさい、でもそれが当時のやり方です。

また、私は毎日のほとんどの時間をこのソフトウェアの作成に費やしています。 新しいバージョンを作成するためにコードを削除する必要がある場合は、それを理解してください。 新しいバージョンと互換性を持たせるために別のPRを作成することもできます

はい、私は今怒っています。 私は何年もの間無料でコードを書き、大部分の作業を行い、多くのサポート作業を行い、ビジネスを作ろうとしました。数千時間とまではいかなくても数百時間の無給労働で得られるのはそれだけです。

もしそれが私の責任感でなかったら、私は2年前にウェブサイトと他のすべてをシャットダウンしたでしょう。

今は1か月生き残るのに十分なお金がなく、すぐに回復する可能性が低いいくつかの病気があり、ほとんど回復できないにもかかわらず、このプロジェクトを何とか生き続けようとしています。

また、私は毎日のほとんどの時間をこのソフトウェアの作成に費やしています。 新しいバージョンを作成するためにコードを削除する必要がある場合は、それを理解してください。 新しいバージョンと互換性を持たせるために別のPRを作成することもできます

はい、私は今怒っています。 私は何年もの間無料でコードを書き、大部分の作業を行い、多くのサポート作業を行い、ビジネスを作ろうとしました。数千時間とまではいかなくても数百時間の無給労働で得られるのはそれだけです。

もしそれが私の責任感でなかったら、私は2年前にウェブサイトと他のすべてをシャットダウンしたでしょう。

今は1か月生き残るのに十分なお金がなく、すぐに回復する可能性が低いいくつかの病気があり、ほとんど回復できないにもかかわらず、このプロジェクトを何とか生き続けようとしています。

あなたが深刻な状況にあることを私は知っています、そしてコミュニティを含むこのプロジェクトはあなたの状況に貢献しています。 私もあなたの仕事を尊重し、このプロジェクトは（特に他のプロジェクトと比較して）よくできている構造を持っていると思います。そうでなければ、このプロジェクトを活性化するために何ができるか、開発チームが必要な作業。
今は過去をウォームアップしたくありません。Partkeeprをさらに進めるのに役立ちません。

私の日常の仕事から、特にその人に到達できない場合、他の人からのコードを処理するのが難しい場合があることを私は知っています（将来のために、そしてそれが必要な場合は、誰もがgitcommitsからの電子メールアドレスまたはドメインを使用して私に連絡することができます私のホームページを使用して私に連絡してください）。 コーディングを書くときは、誰もが独自の手書きを持っています。 私の意見では、コードを書くのは一種の職人技です。 また、ライブラリのアップグレードや多数の依存関係を実行する場合、複雑さとこれを実行するのがどれほど難しいかについて多くの経験があります。 私はこれをチームで何ヶ月も有料の仕事で行いました。
だから今、私たちはここで再びこの課題を抱えており、コミュニティでこれを行う方法を考えなければなりません。 有料の環境のように、それははるかに困難です。

私はコードを見て、最後に何かをしたので、それはたくさんの変更をしました（誰かがここで多くの仕事を投資します!! :)。 そのため、コードをもう一度掘り下げて作業を開始する必要がありました。 しかし、このためには、緊密なコミュニケーションと次に何をすべきかについてのロードマップが必要です。 印刷機能を元に戻すことは、他のものと比較して非常に優先度が低いと思います。私または他の誰かが後でこれを行うことができます。 私にとっては、将来の次のOSアップグレードでデータを失わないほうが価値があります。これは、他の何かに移行するための多くの作業も意味するため（これが何であるかはわかりません）、長い作業が必要でした。データベースを埋めるために私の暇な時間に。

ありがとう@Boldie

@christianlupus @dromer物事が再び動いているので、これを閉じることができると思います...！

議論すべきもう1つのポイント：＃1091の変更により、すべての新しい問題にはいくつかのタグが付けられます。 ここで人間によるレビューが行われていないことを示す指標が必要ですか？

これとは別に、私は今この問題を閉じても大丈夫です。

私たちが行ったことは、人間によるレビューとどのように異なりますか？ :)

@baradhiliこれはまさに私たちが最近やったことです。 つまり、指定されたPRが受け入れられたため、新しい問題には、選択した問題のタイプに応じて、バグ、機能要求、またはヘルプが必要なプリセットのいずれかがラベルとして設定されます。
つまり、新しい問題（最近行った手動トリアージに合格しなかったもの）は、ラベルが添付されていないものとして表示されません。 したがって、GitHubには、まだ人為的にトリアージされていない問題を選択するための単純なフィルターはありません。

つまり、 need-triageなどを表示する必要がありますか。

githubのテンプレートシステムの下にneeds-triageラベルを自動的に追加できますか？

はい、ラベルを追加し、テンプレートファイルの1行を変更するだけです。 それで十分です。

問題テンプレートシステムに関して＃1097を開いたところです。 needs-triageラベルが不要な場合は、単一のコミットを削除することをお勧めします。

今これを閉じます