@JesperSchulz There are different reasons why people would contribute, you have to find the most common/important:
A: Be famous?
B: Get "your" feature/fix into BC?
C: Give back to MS / the community?
C apparently is not the one.
@KarolakNatalie@ajkauffmann @srenders @JamesCrowter@waldo1001 @MeFriis @MSDYN365BC If the developer sets ShowMandatory, but does not implement any logic, that is a bug.
Converse, making a field mandatory, but not showing it as mandatory can be equally as bad.
In my BC Admin center, I get a notifications that advisories are reported but what are they and how do I see them? Nothing happens when I click the icon or the text..
#msdyn365bc
@JeremyVyska I just think many devs have no budget, so it’s either free content or they have to get approval and then the cost is not the biggest issue.
As a manager I want people spending time on really good content, and cost and quality often goes hand in hand.
@eHougaard@waldo1001 You can always have the catch-all procedure:
Process(Input: JsonObject) Output : JsonObject;
Then implicit contract of interface is "give me something and I might do something and give you something back"
@eHougaard@waldo1001 You should always add extra methods on the interface for future use, like this:
[Obsolete(‘Could be not obsolete in the future if we need a procedure that takes an int parameter)]
Procedure1(I: Integer);
etc…
#NotGoodAdvice
@JeremyVyska I don't get why you would need to choose one or the other.
Use BOTH! Github with AL:Go for code the code and pipelines, Azure DevOps for the boards etc.
They work great together with DevOps works items being referenced from Github and the work items linking to all related PRs.
@trickynamics@freddydk You can choose both.
We are trialing Al:Go! on GitHub but keeping the stories and planning in Azure DevOps. References works both ways, a story can reference a PR in GitHub and vice versa.
Looks like a way to get the best of both worlds.