Rules under Work - page 5

 
Yedelkin:
Here's a different approach to the problem at the end :)
No bazaar. )))
 
pronych:

The source can be a well-designed template, with lots of extra features, classes, etc. It may consist of a bunch of blocks (inludes, for example) and only some of the conditions in it may vary. Are you ready to give six months (in a simple case) of work, in the source code of a dozen different files of one system (system, in the sense of interaction with each other), in which only the signal module (one class(file)) differs?

I understand, we can use standard tools to crash crash the masks, and it's not a pity. But if huge efforts are put into the template, how can we do it? No, are you ready?

It turns out that in such cases, it is better to give the template as a compiled file, and the signal module - at the customer's discretion. Would such an option (which has already been mentioned) work for everyone?

...But in that case the risk of a "new build" is transferred to the client, and the guarantee of eliminating that risk is left to the conscience of the contractor.

 
Yedelkin:

There is a fundamental error here. A contract is an agreement between two or more people. An application is just a proposal from one party, which in itself cannot be considered a contract. Based on the essence of the rules under discussion, the formation of a contractual relationship (conclusion of a contract) can only be judged after the Terms of Reference have been drawn up. The terms of reference are intended to reflect all details of the work agreed upon by both parties .


I did not argue that in our case the application is a contract, I only expressed the wish that it should be close to it (i.e. the application in my opinion should contain some mandatory fields / ticks), and the ToR should disclose in more detail the specifics of the work and define certain points that the contractor must adhere to.

That said, I'm sure that at least 60% of non-programmer traders will ignore half of the ToR.

 
Interesting:

I did not argue that in our case the application is a contract ...

Interesting:

... I believe that under normal circumstances a contract (read application)...

As usual, I was commenting on what was highlighted:)
 
Interesting:

That said, I am sure that at least 60% of non-programmer traders will ignore half of the ToR.

That is why I argued and continue to argue that when drafting the ToR (in light of specific rules), the contractor should feel free to take the initiative in coordinating the details of the work and reflecting them in the document. It is the contractor who will have to deal with the complaints of the client. A drafted ToR that is at fault of the Contractor will only serve to stir up unnecessary disputes.
 
Yedelkin:
It turns out that in such cases, it is better to give the template as a compiled file and the signal module at the customer's discretion. Would this option (already mentioned) work for everyone?
Not quite, to everyone.)) However, of course, it's also an option... For me, it's more convenient to have one ready-made file. This complicates the task (read -'cost') But the conversation is not even about it. Such an approach splits the idea, and the customer is not sharp (or sharp! they may be different) in such things, though not a fool )) I think the checkbox "I want sources" is enough, and it just solve most of the issues before agreeing on the terms of reference. If with this issue will be understandable, then you can continue to discuss the job. and there, the grass grows, a completely different stage.
 
pronych:
Not quite, to all of them)) However, it is certainly an option... For me it's more convenient to have one file ready. This complicates the task (read -'cost') But the conversation is not even about it. Such an approach splits the idea, and the customer is not sharp (or sharp! they may be different) in such things, though not a fool )) I think the checkbox "I want sources" is enough, and it just solve most of the issues before agreeing on the terms of reference. If with this issue will be understandable, then we can continue to discuss the job. and there, the grass grows, a completely different stage.

What then? A workable option for solving your problem looks like this:

1. On the formal side, a new clause in the rules;

2. On the technical side - in the form for the Application to introduce option "Source code required" with default "Not required"?

 
Yedelkin:
That is why I have asserted and continue to assert that when drawing up a ToR (in the light of specific rules) the contractor must feel free to take the initiative in coordinating the details of the work and reflecting them in the document. It is the contractor who will have to deal with the complaints of the client. A clumsily drawn up through the fault of the Contractor's requirements specification will only contribute to unnecessary disputes.

Yeah. It's likely. So let's think at once (quietly, while the developers are asleep))), what kind of additions we'd like to ask for in the 'Work' section? But me first!

Check the box! 'Sources'.

:))

 
Yedelkin:

What then? A workable option for solving your problem looks like this:

1. On the formal side, a new clause in the Rules;

2. On the technical side, in the Application form, introduce the option "Source code required" with a default of "Not required"?

Correct
 

In my opinion, there is another, alternative way - there is a mediator-arbitrator (in our case, MQ) between the contractor and the customer, and the contractor gives the whole package of materials + sources to the mediator (who checks them against the TOR), after which the customer receives a notice from the mediator that the work is completed and must pay for it.

Depending on exclusivity of the work and initial arrangements after the payment the client receives the maximum open source code or just the compiled files.

In this case as you understand the intermediary receives a certain remuneration.

PS

Although it seems to me MQ doesn't like it very much...

Reason: