作業中のルール - ページ 3

[Aleksey]

Yedelkin:
繰り返しになりますが、私は反論しません。しかし、先に指摘したように、請負人は「仕事をすることの申し出 」を掲示するのであるから、このような関係では受動的な当事者とはいえない。そのオファーの中にある「ソースは15倍かかる」という一文を、執行人候補者が即座に述べられない理由が私には理解できない。あるいは「ソースは売らない」。これ以上時間を浪費することはない。顧客は同意してこの応募者を選ぶか、あるいは忘れてしまうのである。

まあ、それもそうなんですけどね。ただ、応募リストにこの欄があれば、そもそも期待していない人のところに行かなくて済むので、ずっと便利だと思います。

私が言いたいのは、こういうことです。いずれにせよ、遅かれ早かれ、手に入れることになると思います。少なくとも私はそう願っています。

[Aleksey]

そして、ルールにおいては、やはりこの区別を明示的に記すべきでしょう。ファイル」だけではありません。

IMHO

[Yedelkin]

pronych:

まあ、それもそうなんですけどね。ただ、応募リストにこの欄があれば、そもそも期待していない人のところに行かなくて済むので、ずっと便利だと思います。

私が言いたいのは、こういうことです。いずれにせよ、遅かれ早かれ、手に入れることになると思います。少なくとも私はそう願っています。

応募者にとって都合がいいというのは、私も同感です。私からのアドバイスは、「ルール」に欲しい具体的なフレーズ（文章）を策定することです。そうすれば、モデレーターがそのような文言をルールに挿入するのは1分程度のことである。

[Aleksey]

Yedelkin:
応募者にとって都合がいいというのは、私も同感です。ルールに欲しい具体的なフレーズ（文言）を策定することをお勧めします。そして、モデレーターがそのような用意周到な文言をルールに挿入するのは、1分程度のことです。

ええ、まあ...確かに、こんなオファーが来るとは思っていなかった。ありがとう、クールダウンした )))

そのルールがどのように受け入れられたのか、想像がつきます))。

見せてください。そうするかもしれませんね。))

皆さんに提案したいのは、「一緒に考えよう」ということです。

[Yedelkin]

pronych:

みんなに提案したいのは、「一緒に考えよう」ということです。

クライアントによる最初の申請の話なので、ルールの第1節で明確にするのが合理的です。例えば、新しい条項 3.1 を挿入する。「3.1. 注文書には、作業の期待される結果（ソースコードまたはコンパイルされたファイル）の表示が含まれていなければならない」。

[Aleksey]

Yedelkin:
使用者による最初の申請ということですから、規則第Ⅰ条を明確にするのが妥当でしょう。例えば、新しい条項3.1を挿入すること：「3.1. 注文書には、作業の予想結果（ソースコードまたはコンパイルされたファイル）の表示が含まれていなければならない」。

それはそれで問題ないと思うのですが。気の利いたことは言わない。どこに置けばいいのか、よくわからないんです。

そうかもしれませんね。ところで、契約は少し単純だと思う。 義務もなく、権利もなく......。

それだけです。もういい加減にしてほしい。どう表現したらいいのかわからない。

でも、高ければ高いほどいい・・・。

[Yedelkin]

pronych:

それはそれで問題ないと思うのですが。気の利いたことは言わない。どこに置けばいいのか、よくわからないんです。

そうかもしれませんね。ところで、契約は少し単純だと思う。 義務もなく、権利もなく......。

それだけです。もういい加減にしてほしい。どう表現したらいいのかわからない。

:)さて、このフレーズ自体は満足できるものでしょうか？そして、それを作業用バージョンとする :)

[削除済み]

Yedelkin:

契約」とは何ですか？- それは単に、ある重要な条件について当事者間で合意したものです。この文書自体は「契約書」とは呼べないかもしれません。書面でない場合もあります。私たちがお店で何かを買うとき、レシートをもらうだけですが、この場合、レシートは書面にしなくても売買契約の成立を確認するものだからです。

同規則によると、ジョブチケットは顧客と請負業者の間の契約のすべての必須条件を含んでいなければならない、すなわち、その法的性質上（用語は失礼ですが）仕事は仕事の契約である（民法第702条）とされています。そのような文書の具体的な性質から、ToRと呼ぶことにしたというだけです。

現行スキームでは（MQが提案した）ToRが基本であることは既に示したとおりです。したがって、できるだけ多くの情報を反映させる必要があります。

[Yedelkin]

Interesting:
現行スキームでは（MQが提案した）ToRが基本であることは既に指摘したとおりです。したがって、できるだけ多くの情報を反映させる必要があります。

...そして、「どう正しいかはわからないが、個人的にはTORは二次的なものであり、契約（申請）の付録でしかないと思っている」と付け加えた。それを、コメントしたフレーズにハイライトを 入れました。コメントの本質：ある条件下では、ToRは自給自足（あなたの用語ではプライマリー）できるかもしれません。そうですね、言葉通りです、やはり争う対象がないですね :)

[Aleksey]

一般的には、ルールをごちゃごちゃにせず、単純に、リクエストを入力する際に、「ソースが欲しい」などの「非選択」のチェックボックスを追加して、仕事のリストに反映させるのが一番簡単な方法でしょう。