Build folder

[ravage84]

Wouldn't the quite popular build folder be a candidate for inclusion? I guess it didn't show up in the research data, as most projects only create it while building and delete it again afterwards.

But nonetheless it is quite common in many build automation tools, continuous integration tools and projects like this one, for example.

[pmjones]

Hiya -- well, it shows up in the research results, but at a low frequency: 987 out of 65617.

However, the draft as written does neither requires nor rejects the presence of a "build" directory; it says nothing either for or against having one at the root.

[ravage84]

How about recommending it? This way the standard recommends something, which is very common already (though not proved by your research data, I have to admit).

[pmjones]

though not proved by your research data

I shy away from the word "proved" here -- it is merely "not revealed."

Even so, I think you see the direction I'm coming from; I don't think requiring or recommending it is supported by the research. I think there's enough "judgement" involved as it is.

(As a side note, I'm wary even of recommending a LICENSE document, not because I think licensing is a bad idea, but because it opens up precedent to recommending things not necessarily supported by the research itself. Cf. #1 )

[ravage84]

Well, then I fear this standard could become too research based. Do you want to base it only on your research and what it revealed in those four iterations?

If the research is so important for the decision making on this standard, then it might be even pointless to discuss views and experiences any further.

Don't get me wrong, I don't mind not including the build folder. All I fear is that this standard is simply a replication or summarization of de-facto standards already in place .

How would you further develop this standard? Wait some time, do research again on the matter and then summarize again? Or would you actively develop a standard with the community through discussion or whatever it takes?

[pmjones]

All I fear is that this standard is simply a replication or summarization of de-facto standards already in place .

That is in fact its intent: to reveal the common approaches revealed by examining the wider package ecosystem. Cf. the mission statement from http://php-pds.com:

This initiative researches the PHP package ecosystem to recognize commonly adopted development practices. It rationalizes and refines those practices, then publishes them as PDS packages for reference by PHP package authors.

PDS publications are derived from and supported by common practices existing in real packages, as adopted by existing authors who have a continuing interest in the quality and consistency of their own work.

I do want to highlight that this does not get in the way of individual expansions on the standard, which is one reason why the publication uses the "if/then" phrasing.

[ravage84]

It rationalizes and refines those practices

How much research data interpretation does that allow and by whom?

How far does this refinement go? Where dos it stop?

[pmjones]

Where dos it stop?

At the shortest possible distance away from the research. ;-)

[Revisor]

What is the directory used for in PHP packages? If it's used eg. for the output of PHPUnit, it's .gitignored anyway and it's more a function of the environment and extraneous tools than of the package itself, no?

[pmjones]

Overall, I think the low frequency of use, as revealed by the research, means that it is not a candidate for explicit inclusion in the standard. Note that this does not mean the standard prohibits it, only that it does not require a specific name for this kind of directory.