I don't know about BEST practice, but if we ever cleaned up our actual practice, it would probably look something like this:
Publisher_Master
Accounting
QVD
Commercial
Inventory
Master_Data
QVD
Operations
Payroll
QVD
Transportation
There are certainly more directories, but that's the basic idea, and now I'll explain. Each big category of the type of data has its own directory. These directories have separate access control over who can get to the applications within. The Master_Data directory contains most of the QVWs that do nothing but create QVDs, and the results go in the QVD sub directory. Some categories of data, like accounting and particularly payroll data, are sensitive enough that they should be protected from most people in IT as well. So the sensitive QVDs go into those specific directories so that access is more tightly controlled. The QVWs that create those QVDs obviously go in the controlled directories as well.
We don't have any issues with concurrent development because for the most part, each QVW has an owner, specified on a fairly standard format About tab. Some of the QVWs in the Master_Data directory don't have an owner, but they're rarely touched, and we at least often chat about what we're doing even if we don't have an official check out policy for them, so we've never had any problems that I'm remembering. For an environment with 10+ developers, unless you have an owner for each application, you'll probably need something more sophisticated than "hey by the way, I'm adding some fields to this QVD". I'd recommend some sort of code versioning and collaboration software. I have no specific recommendations as far as what software to use. If you don't want to go that far, perhaps you could implement a policy where if you want to develop an application, you copy it from the server and put your name at the end (e.g., Customer_Orders.qvw.JohnWitherspoon). Then when you're done, copy it back and remove the old file. If someone sees your name on a file, they know you have it checked out and know who to talk to.
As far as standard practices, we initially tried to create some standards documentation. This has not been followed. I haven't followed it. I'd rewrite it now to match my own practices, but that wouldn't change anything.
Perhaps a good approach would be to set up a template with examples of everything from your standard color scheme to how date fields look and how line charts should look. We haven't done that, and I don't know if that would be effective in practice.
Something I've recently done that I wish I'd done a lot earlier is set up a Calendar QVD. This lets me stop repeating calendar logic (however simple it is in practice), and makes sure that all applications using the standard Calendar also get the standard formatting for dates, months, quarters and so on. If you can do something like that and get everyone to use it, that might help with enforcing standards.
This is pehaps only peripherally related to the question, but I recommend forbidding developers to EVER load * from any data source but an inline or resident table. If your application doesn't have control over the source, never ever load *. Yes, when your QVD only has 10 fields, and you want those 10 fields, listing them all may seem like a pain. But that is NOTHING compared to the pain you'll suffer when someone adds another field to that QVD that they require, and then your application reads it in, and then it links up your data models in incorrect ways, and breaks your application. And even if it doesn't break your application, the slow accumulation of fields you don't need in your tables will take more and more memory and make your application slower and slower. Multiply that by 10+ developers and 100+ of applications, and hopefully you can see the problem. A little investment up front can save a lot of trouble later.
