matsuand です。 > ひとつお願いがあるのですが、ファイルひとつのテキストはメール本文にして > いただけると非常に助かります。スマホで見ていると、gzip 形式の添付ファイルは > 読めないので、展開して読める環境で、さらにそのときに時間がある場合しか、 > 反応はおろか読むことさえできないので、どうしても遅くなります。 本メールにて後段に、テキスト全文を貼り付けます。 なお上に頂いた話は、これはこれでプロジェクトポリシーに関わる 問題であると思います。テキスト１つの場合は、全文を貼り付ける、 といった定めはありましたか？ ないですよね？ 圧縮形式の定めは？ ・・・ そのうち私が作りましょう。今は堅苦しく捉えずに。 ---- 以下 con_discuss.rst ファイル ---- .. 本ファイル (con_discuss.rst) 命名の意味： .. "con": constitution(憲章)の略； プロジェクト憲章の意味。 .. "discuss": discussion(協議)の意味。 ====================== 標準協議手続き (素案) ====================== * 2021/05/28 素案提示。 はじめに ======== 本文書は Linux JM プロジェクトに対して行う提案や協議に関する標準的な手続きを定めるものです。 提案を行った後は協議を経て投票を行い、その可否を判断します。 詳しくは「:ref:`discuss-procedure`」において順に説明します。 なお説明にあたり以下の用語を定義します。 * 「当プロジェクト」： Linux JM プロジェクトのこと。 * 「プロジェクトメンバー」： Linux JM プロジェクトを実現提供している OSDN サイト (https://osdn.net/projects/linuxjm/devel/) において、メンバー承認されている者すべて。(以下、この OSDN サイトのことを単に「OSDN サイト」と呼びます。) * 「プロジェクト管理者」： OSDN サイトにおいて、プロジェクト管理者として登録されている者すべて。「プロジェクト管理者」は「プロジェクトメンバー」に含まれます。 * 「一般ユーザー」： 「プロジェクトメンバー」には該当せず、ただし後述のメーリングリストのメンバーとして登録されている者すべて。（メーリングリストに未登録であっても、メーリングリスト管理者によりメール投稿が承認された者を含みます。） * 「本手順」： 本文書において説明する手順全般のこと。 .. _discuss-procedure: 協議手順 ========= 提案 ----- 提案とは、当プロジェクトのサービス提供方法や内容、運用手順に対して、新たな内容の追加、既存内容の修正、廃止などの案を提起することを指します。 提案は、メーリングリスト linux****@lists***** に内容を投稿することで、プロジェクトメンバー、一般ユーザーが提起できます。(以下、このメーリングリストを単に「メーリングリスト」と呼びます。) 提案を行った者を「提案者」と呼びます。 提案を行うメールの書式に定めはありません。提案であることがわかるようなメール件名、メール内容とします。 提案は当プロジェクトの発展に寄与する建設的なもの、適正なものであることが必要です。 建設的、適正であるかどうかは、最終的にプロジェクトメンバーが判断します。 (ただし提案者がプロジェクトメンバーである場合、提案者はその提案に限りこれを判断する資格を失います。) 建設的でない、または適正でないと判断された場合、提案が却下されることがあります。 協議 ----- メーリングリストに提案が投稿された後は、協議が開始されます。 協議はメーリングリスト上において、プロジェクトメンバー、一般ユーザーが参加できます。 ただし一般ユーザーの場合は、協議に参加はできますが、後述する投票には原則として参加できません。 協議に参加した者を「協議者」と呼びます。 協議の開始が周知されるための最低期間として **一週間** を置くものとします。 これを「協議期間」と呼びます。 協議は、原則としてその提案者が議事進行に努めます。 提案内容への質問対応、必要に応じた提案内容の修正、再提案、協議結果のとりまとめなどを行います。 協議は当プロジェクトの発展に寄与する建設的なもの、適正なものであることが必要です。 建設的、適正であるかどうかは、最終的にプロジェクトメンバーが判断します。 (ただし提案者がプロジェクトメンバーである場合、提案者はその提案に限りこれを判断する資格を失います。) 建設的でない、または適正でないと判断された場合、その対象となった発言を採用しない、協議が中断される、提案そのものが却下されることがあります。 投票 ----- 投票の要求 ^^^^^^^^^^^ 協議期間が **一週間** 経過した後、提案者は投票を要求することができます。 提案者が一般ユーザーである場合、この要求はプロジェクトメンバーが代行することができます。 (代行したそのプロジェクトメンバーは提案者に含まれるものとします。) 投票はメーリングリスト上において、その要求を宣言します。 投票要求を行うメールの書式に定めはありません。投票を要求することがわかるようなメール件名、メール内容とします。 投票の要求が周知されるための最低期間として **一週間** を置くものとします。 これを「投票期間」と呼びます。 投票と結果集計 ^^^^^^^^^^^^^^^ 提案者は、メーリングリストを介して投票を促し、投票結果を得ます。 投票が可能な対象者は、プロジェクトメンバーと提案者のみです。 一般ユーザーは原則として投票に参加することはできません。 ただし一般ユーザーが提案者である場合は、投票することができます。 .. note:: 提案者が一般ユーザーである場合、自分自身の提案に対して賛成票を投じることができます。 この投票は有効となります。 これは自分が提案しているから認められるものであって、提案者ではない一般ユーザーは投票することはできません。 投票を行ったとしても、その投票集計からは除外されます。 それまでの協議期間内での意見集約ができている場合は、それをもって投票結果とみなすことができます。 投票期間経過後、提案者は賛成票、反対票の数を集計して結果を得ます。 投票結果の確定 ^^^^^^^^^^^^^^^ 投票結果は原則として **多数決により賛成、反対を決定** します 。 この場合に一般ユーザーによる投票は、その一般ユーザーが提案者である場合は有効な票として扱います。 逆に提案者でない場合は無効な票として扱います。 投票結果の確定にあたっては、提案者が一般ユーザーかプロジェクトメンバーかによって異なります。 また賛成、反対が同数であった場合の決定の仕方を設けています。 提案者が一般ユーザーである場合： * 必ずプロジェクトメンバーの投票が行われていることを条件とします。 これが行われていない場合は、**否決** とします。 左記条件を満たした上で多数決により結果確定します。 ただし賛成反対が同数となった場合、**否決** とします。 提案者がプロジェクトメンバーである場合： * 参加した投票者の状況を考慮することなく、単純に多数決により結果確定します。 ただし賛成反対が同数となった場合、**提案者の案** (賛成票) を採用します。 賛成、反対の結果をその票数とともに、提案者はメーリングリスト上において報告します。 結果が賛成となった場合、その後の実際の作業フローに引き継ぎます。 結果が反対となった場合、提案は却下されます。 特記事項 ======== .. _eligibility: 協議や投票の適格性 ------------------- 本手順は、できる限り提案者の案を採用する仕組みとなるように策定しています。 ただし協議や投票は、いずれも当プロジェクトの継続的なサービス提供、将来の発展に向けた建設的で適正な内容であることを前提としています。 したがって以下に該当するものは、プロジェクトメンバーによって、協議の中断、投票結果の無効化を行うことがあります。 1. 当プロジェクトの継続的サービス、発展に寄与しない、あるいはこれを阻害するなど、これにあたる相当な事由があるものとして、プロジェクトメンバーが判断するもの。 2. 当プロジェクトの現状のサービス提供内容や現行運用に多大な影響を及ぼし、実現不能、実現困難、現実的な実現可能性が低い内容であるものとして、プロジェクトメンバーが判断するもの。 3. その他、相当な事由があって採用不可、実現不可であるものとして、プロジェクトメンバーが判断するもの。 なお上記の適格性を判断するプロジェクトメンバーが複数存在し、その意見が分かれる場合は、プロジェクトメンバー内において真摯に協議して結論を得るものとします。 本手順悪用への対処 -------------------- 一般に協議検討を進めていく際には、意見の対立が起きて、決議にまで至らないことはよく発生するものです。 その点、本手順では決議が進みやすくする仕組みとして、提案期間や投票期間を無期限ではなく有限 (最低一週間) とし、また特にプロジェクトメンバー発信による提案の場合は、提案者の案が採用されやすくなるようにしています。 ただしこうした仕組みを設けたとしても、協議検討が必ずしも順当に進まないことが想定されます。 たとえば本手順に準拠して 1 つの提案が協議されている状態で、これにどうしても賛同できない者が、全くの真逆となる提案（逆提案と呼ぶことにします）をあげたら、元の提案を簡単に覆すことができます。本手順は逆提案に対しても、容易に採用されやすい仕組みにもなっているからです。 このような状態は望ましいことではありません。 本手順はこういった逆提案を無効とするような仕組みは設けていません。 そのような事態に至った場合には、関係者により十分な協議が行われ、解決に向かうよう尽力することとします。 本手順に準拠した提案、協議、投票は、すべて当プロジェクトのサービス向上、継続的発展を目指すように心がけるものであり、関係者が真摯にその目的のために行動することを前提としています。 協議、投票に関する現実的なケース解釈 ===================================== 現実問題として、協議や投票が活発には行われないケースがあることは十分に想定されます。 そのようなケースを以下に取り上げます。 極端なケースを取り上げることにより、それがどのようにして進められていくかを解説します。 これを通じて本手順の理解に役立ててください。 一般ユーザーの提案、ただし協議が不活発な場合 -------------------------------------------- 提案者が一般ユーザーであり、これに対して協議者がいない (投票を要求しても返信がない) というケースです。 提案をあげると協議期間となり、投票要求を行えば投票期間となるところまで進行します。 ただし「投票結果の確定」にて示しているように、一般ユーザーが提案者となっている場合、投票結果確定のためには、プロジェクトメンバーの投票が行われていることが必須条件です。 したがってプロジェクトメンバーが投票を行わない限り、その提案は否決扱いとなります。 また仮に、投票を行うプロジェクトメンバーがただ 1 人であったとして、そのプロジェクトメンバーが反対票を投じた場合、提案者自身による賛成 1 票と、そのプロジェクトメンバーによる反対 1 票の同数となり、その場合、「投票結果の確定」に示しているように、同数なら否決扱いとなります。 一般ユーザー発信による提案の場合は、プロジェクトメンバーの判断が加わっている必要があり、さらにプロジェクトメンバーによる賛成票が上回らなければ採用されない、という仕組みとしています。 プロジェクトメンバーの提案、ただし協議が不活発な場合 ----------------------------------------------------- 提案者がプロジェクトメンバーであり、これに対して協議者がいない (投票を要求しても返信がない) というケースです。 提案をあげると協議期間となり、投票要求を行えば投票期間となるところまで進行します。 そして一般ユーザーの提案時 (前述) の場合と違って、投票結果を集計して確定するところまで、すべてを進めることができます。 これは最も極端なケースとして、提案者以外のプロジェクトメンバーが誰も返信しなかったとしたら、提案者自身の賛成 1 票のみとなり、その提案は多数決採用されることを意味します。 当然のことながら「:ref:`eligibility`」に示した項目に該当する場合には、必要に応じて協議の中断、投票の無効化を行わなければならないため、提案者以外のプロジェクトメンバーが、鋭意その動向には注視するものとします。 プロジェクトメンバー発信による提案の場合は、協議や投票が行われなくても、「:ref:`eligibility`」に示す項目に該当しない限りは、極力アイデア提起を行った提案者の労を尊重して、その提案に従う趣旨です。そしてこのような仕組みとすることにより、プロジェクトメンバー内から発せられるアイデアを埋もれることなく、早期に実現していく発想に基づいています。
Fork