Last time edited on 2015-03-09T19:24:43+00

There isn't a repository contributor guideline on Orleans as of yet. I think it should provided. What do you think should be in it?

Some food for thoughts in the following.The main idea is to make the process scalable, "self-driven" when it comes to daily routines.

Write guidelines for the development and design flow

• Design on branching and tagging model, as discussed at Ideas for contributions #29 (here and here), also touched upon Downgrade dependency on Microsoft.WindowsAzure.ServiceRuntime to 2.4 #197 (surely we shouldn't encourage private forks).
• How to take in external libraries as they increase library conflicts, touched upon at Management of internal and application dependencies #200 and at PowerShell Snap-In Prototype #150 (here).
• A guideline with Git commands and other appropriate helpers from cloning to a pull request and what ought to be checked there. Perhaps there should reasoning for the guidelines. For instance, why history should look certain so as to facilitate making conclusions out of it.
• Experimenting, ideas and so forth aren't frowned upon. Messing up one's branch, core or someuch in a public PR isn't an issue as long as the code ending up the main repo is acceptable. To err is human and everything can be fixed.
• Encourage research extensions?

Qualities and guidelines in order of important (e.g. bug fixes)

1. Security
2. Scalability (& performance)
3. Reliability
4. Maintainability (the Orleans development, debugging and testing story ought to be: clone the repo, hit F5).
5. ???

How to enforce the above mentioned? For instance, security should be important, in my opinion, but I don't know how to systematically and explicitly check security issues other than that if there are two otherwise equally important bugs, I'd fix the one with security problem first. Likewise when developing a new feature, it should developed so as to not expose a vulnerability even if other quality might warrant making such a decision, for instance scalability. That is, perhaps scalability is important and scalability features are designed and implemented, but if security problem is found, it should be fixed.

<edit 2015-03-09T19:13:43+00>
A first draft of Orlean mission statement? By @gabikliot.
</edit>

Reviewing code

• Conforms to .NET Framework Design Guidelines unless a reason argued in comments. When using Visual Studio, Code Analysis could be set to a certain level.
• Prefer checking parameters always on public (internal?) and protected interfaces (perhaps on private too) as per Parameter Design Guidelines and currently point 2. on qualities list. Other way to phrase this is in the language of invariants or pre- and post-conditions, pointing also to Code Contrats. Should they be considered?
• Has comments at least on the public surface. Or also anything that is non-trivial (example).
• Favour making structs, classes and functions immutable (immutable collection parameters, immutable return values or copies) when feasible. Should it commented in the code if, say, a collection given as a parameter will be mutated or a new one given as return value?
• When programming classes, when feasible, favour style where functions take parameters and return values over style where functions (procedures in old Pascal parlance) return void and take no parameters and instead mutate object state. This makes following the code easier, easier to test and consequently more robust and amenable to refactoring.
• How stringent on tests? Should pass, naturally. Core functionality should include, otherwise actively encouraged?

<edit 2015-03-09T19:24:43+00>
Some preliminary guidelines on checking parameters. By @gabikliot.
</edit>

That's about my first round of shedding ideas. Any others? I reckon some of these are controversial, such as the one with functions. What guidelines other .NET repos have?