Yedelkin : 다시 말하지만, 나는 논쟁하지 않을 것이다. 그러나 이미 앞에서 언급했듯이 계약자는 "작업 수행에 대한 제안 "을 배치하기 때문에 그러한 관계에서 수동 당사자가 아닙니다. 잠재적 계약자가 제안서에서 즉시 "소스 코드 비용이 15배 더 들 것"이라는 문구를 표시하지 못하게 하는 이유를 이해할 수 없습니다. 또는 "나는 소스 코드를 거래하지 않습니다". 더 이상 시간 낭비가 없을 것입니다. 고객은 동의하고 이 신청자를 선택하거나 그를 잊어버립니다.
글쎄요, 그것도 사실입니다. 애플리케이션 목록에서 이 체크박스를 보는 것이 훨씬 더 편리할 것입니다. 그리고 처음에 당신을 기다리지 않는 사람과 텅 빈 자리에 끼어들지 마십시오.
나는 무엇을 하러 왔다. 어쨌든 조만간 우리가 이 문제에 도달하게 될 것이라고 생각합니다. 적어도 바랍니다.
우리는 고객의 초기 애플리케이션 실행에 대해 이야기하고 있기 때문에 규칙의 섹션 I을 명확히 하는 것이 합리적입니다. 예를 들어, 새로운 단락 3.1을 삽입하십시오. "3.1. 주문에는 작업의 예상 결과(소스 코드 또는 컴파일된 파일)에 대한 표시가 포함되어야 합니다."
Yedelkin : 우리는 고객의 초기 애플리케이션 실행에 대해 이야기하고 있기 때문에 규칙의 섹션 I을 명확히 하는 것이 합리적입니다. 예를 들어, 새로운 단락 3.1을 삽입하십시오. "3.1. 주문에는 작업의 예상 결과(소스 코드 또는 컴파일된 파일)에 대한 표시가 포함되어야 합니다."
아마도 문제는 나를위한 것이 아닙니다. 나는 똑똑하지 않을 것이다. 이걸 어디에 넣어야 할지 잘 모르겠습니다.
당신이 옳은 것 같다. 그건 그렇고, IMHO, 계약은 간단합니다. 의무도 권리도 아니다.
"계약"이란 무엇입니까? - 이것은 특정 필수 조건에 대한 당사자의 합의일 뿐입니다. 이 경우 문서 자체를 "계약"이라고 하지 않을 수 있습니다. 그리고 서면으로도 안됩니다. 상점에서 물건을 구입할 때 수표 외에는 아무것도 받지 않습니다. 이 경우 수표는 서면으로 공식화하지 않고 판매 계약의 체결을 확인하기 때문입니다.
규칙에 따르면 참조 약관에는 고객과 계약자 간의 계약의 모든 필수 조건이 포함되어야 합니다. 법적 성격에 따른 참조 조건(용어 죄송합니다)은 근로 계약입니다(러시아 연방 민법 702조). 단순히 그러한 서면 문서의 특성 때문에 그들은 참조 약관이라고 부르기로 결정했습니다.
기존 방식(MQ가 제안한)에서는 TK가 기본이라고 위에서 이미 지적했습니다. 따라서 최대한의 정보를 반영해야 합니다.
Interesting : 기존 방식(MQ가 제안한)에서는 TK가 기본이라고 위에서 이미 지적했습니다. 따라서 최대한의 정보를 반영해야 합니다.
... 그러면서 "어찌가 맞는지는 모르겠지만 개인적으로 TK는 부차적인 것이고 계약서(신청서)의 부록일 뿐이라고 생각한다"고 덧붙였다. 댓글이 달린 문구 의 강조 표시 와 함께 내가 댓글을 달았습니다. 논평의 핵심: 특정 조건이 충족되면 TK는 자급자족할 수 있습니다(귀하의 용어로는 기본). 글쎄요, 그건 그렇고, 결국 논쟁의 대상이 없습니다. :)
일반적으로 가장 쉬운 방법은 규칙을 똑똑하게 하는 것이 아니라 응용 프로그램에 들어갈 때 "소스 코드를 원합니다"와 같은 "제거됨" 확인란을 추가하고 이를 작업 목록에 반영하는 것입니다. 그것을 필요로 하는 사람은 상자를 체크할 것입니다. 작은 업데이트지만 얼마나 좋은지. 모든 사람에게 모든 것이 즉시 명확해집니다.
다시 말하지만, 나는 논쟁하지 않을 것이다. 그러나 이미 앞에서 언급했듯이 계약자는 "작업 수행에 대한 제안 "을 배치하기 때문에 그러한 관계에서 수동 당사자가 아닙니다. 잠재적 계약자가 제안서에서 즉시 "소스 코드 비용이 15배 더 들 것"이라는 문구를 표시하지 못하게 하는 이유를 이해할 수 없습니다. 또는 "나는 소스 코드를 거래하지 않습니다". 더 이상 시간 낭비가 없을 것입니다. 고객은 동의하고 이 신청자를 선택하거나 그를 잊어버립니다.
글쎄요, 그것도 사실입니다. 애플리케이션 목록에서 이 체크박스를 보는 것이 훨씬 더 편리할 것입니다. 그리고 처음에 당신을 기다리지 않는 사람과 텅 빈 자리에 끼어들지 마십시오.
나는 무엇을 하러 왔다. 어쨌든 조만간 우리가 이 문제에 도달하게 될 것이라고 생각합니다. 적어도 바랍니다.
그리고 규칙에서 그러한 구분을 분명히 주목할 가치가 있습니다. "파일"뿐만이 아닙니다.
임호
글쎄요, 그것도 사실입니다. 애플리케이션 목록에서 이 체크박스를 보는 것이 훨씬 더 편리할 것입니다. 그리고 처음에 당신을 기다리지 않는 사람과 텅 빈 자리에 끼어들지 마십시오.
나는 무엇을 하러 왔다. 어쨌든 조만간 우리가 이 문제에 도달하게 될 것이라고 생각합니다. 적어도 바랍니다.
지원자에게 매우 편리하다는 데 동의합니다. 규칙에서 보고 싶은 특정 문구(제안)를 공식화하는 것이 좋습니다. 그런 다음 이러한 기성 문구를 규칙에 삽입하는 것은 중재자에게 1분의 문제입니다.
예 ... 그런 제안을 기대하지 않았습니다. 멋진 감사합니다)))
이 규칙이 어떻게 채택되었는지 궁금합니다.))
글쎄, 나는 지금 추측 할 것이다. 혼란스러울 수 있습니다. ))
모두 함께 고민해 보시길 바랍니다.
모두 함께 고민해 보시길 바랍니다.
우리는 고객의 초기 애플리케이션 실행에 대해 이야기하고 있기 때문에 규칙의 섹션 I을 명확히 하는 것이 합리적입니다. 예를 들어, 새로운 단락 3.1을 삽입하십시오. "3.1. 주문에는 작업의 예상 결과(소스 코드 또는 컴파일된 파일)에 대한 표시가 포함되어야 합니다."
아마도 문제는 나를위한 것이 아닙니다. 나는 똑똑하지 않을 것이다. 이걸 어디에 넣어야 할지 잘 모르겠습니다.
당신이 옳은 것 같다. 그건 그렇고, IMHO, 계약은 간단합니다. 의무도 권리도 아니다.
모든 것. 나에겐 충분하다. 제대로 공식화해서 삽입하는데, 어떻게 되는지 모르겠습니다.
하지만 높을수록 좋은...
아마도 문제는 나를위한 것이 아닙니다. 나는 똑똑하지 않을 것이다. 이걸 어디에 넣어야 할지 잘 모르겠습니다.
당신이 옳은 것 같다. 그건 그렇고, IMHO, 계약은 간단합니다. 의무도 권리도 아니다.
모든 것. 나에겐 충분하다. 제대로 공식화해서 삽입하는데, 어떻게 되는지 모르겠습니다.
"계약"이란 무엇입니까? - 이것은 특정 필수 조건에 대한 당사자의 합의일 뿐입니다. 이 경우 문서 자체를 "계약"이라고 하지 않을 수 있습니다. 그리고 서면으로도 안됩니다. 상점에서 물건을 구입할 때 수표 외에는 아무것도 받지 않습니다. 이 경우 수표는 서면으로 공식화하지 않고 판매 계약의 체결을 확인하기 때문입니다.
규칙에 따르면 참조 약관에는 고객과 계약자 간의 계약의 모든 필수 조건이 포함되어야 합니다. 법적 성격에 따른 참조 조건(용어 죄송합니다)은 근로 계약입니다(러시아 연방 민법 702조). 단순히 그러한 서면 문서의 특성 때문에 그들은 참조 약관이라고 부르기로 결정했습니다.
기존 방식(MQ가 제안한)에서는 TK가 기본이라고 위에서 이미 지적했습니다. 따라서 최대한의 정보를 반영해야 합니다.