Runtime: Survey: Repo contribution experience, Fall 2020

Created on 18 Nov 2020  路  11Comments  路  Source: dotnet/runtime

We normally focus on how to improve the product, but we鈥檙e also turning our focus to improving the open source project. Periodically we are running a survey to collect feedback on your experience working with our repos. We did one back in May, and as its been about 6 months, its about time for another. We鈥檝e created a survey to better understand your individual experience of participating and contributing in this project.

We would appreciate your feedback so we can work to address shortcomings and missed opportunities.

Survey

Thank you for your time!

area-Meta untriaged

Most helpful comment

All 11 comments

I am checking every issue and every pull request on MonoVM everytime everyday.
I hope you can take more attention and focus to work on MonoVM.
The AssemblyLoadContext and profiler is always not full supported on MonoVM.
and make more performation optimization.

I am waiting for these since last year.
Thank you for your great work.

The most big problem is slow progress, some importance features like AssemblyLoadContext on MonoVM but you can tolerate them in not completed state. It is much hurt to who like .net.
If the apple company project at your speed, I think the macOS transition to apple silicon should not make it.
I am sorry to said these with wish .net can make more and more powerful.

If we regularly interact with multiple repos listed on the survey, should we complete the survey more than once?

If you don鈥檛 supply contact details, then responses will be anonymous.

Should have I been prompted for them? Not really a big deal, but I was a bit surprised when the survey just ended without it asking.

Any chance we will get the results of this survey? And when does the survey ends?

@Symbai They have in the past, so I'd assume they will.

hello @samsp-msft,
Thanks a lot for that opportunity

As a general feedback about multiple repo using dotnet/arcade
(mainly)
dotnet/aspnetcore
dotnet/runtime

I think that one of the biggest show stopper we encountered at work was the proxy on the build tool chain. (especially NTLM-v2 proxy ... because life it more fun with 407)
We ended up having to bring our own (personal) laptop at work to work on Pull Request ... to add proxy support to SignalR and Azure SignalR Service SDK (the irony :D)

The way dotnet/arcade works make it quite complex to change the restore behavior.
At that time, the list of nuget feed were not centralized in a single place.

The only way we have to hit myget.org or nuget.org was though a JFrog Artifactoy so I have to find out the AdditionalRestoreSource or other, create equivalent feed / change URI in repo
and repeat it over and over

I understand that I could possibly attempt to use HTTP(s)_PROXY and so on but at that time it was not properly respected in dotnet/runtime (multiple fixes had to land in 2.1/2.2 and 3.0)
I honestly think that restore.cmd|ps1|sh should support a -Proxy http://localhost:1234 that should be passed down

This issue don't not just concern dotnet restore (for httpclient in dotnet/runtime ), it's also a pain point in pwsh during Invoke-WebRequest and so on.
I understand that this scenario might not be frequent "over the world", but at least 3 attempt of PR were discarded by teamted because they could not restore the repo

Note that this scenario is not just for contribution, but also when you want to debug the sample provided:
We wrote an IHubProtocol with protobuf as a serialization format, and having the opportunity to debug the existing MessagePackHubProtocol was very important in that scenario

so based on all of this .... it's not really clear hwo should I answer to this :
That's a Schr枚dinger build ... both easy and almost impossible :D
image

No https://github.com/dotnet/SqlClient ?

Good point @Wraith2 - we'll hopefully include them next time.

Should have I been prompted for them? Not really a big deal, but I was a bit surprised when the survey just ended without it asking.

Thanks, edited text above since we didn't include that this time.

From time to time I'm working on _dotnet/runtime_ repo and development on Linux is a bit complicated. I had spend a lot of time to fight with debug from vscode but without luck. The same story with code navigation. Additionally, there are some issues with the tools such as dotnet shipped with repo and relative paths. I believe that experienced *nix user and developer can solve these problems locally in an hour, but this looks like unfriendly if you trying to contribute first time.

@sakno thank you for that info. Can you open an issue for that? As well as putting in the survey

@danmosemsft , I have already passed survey. Cloned repo is now configured to work properly on my linux workstation, so I will try clone it from scratch and pass through this path again to collect all the issues.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

btecu picture btecu  路  3Comments

sahithreddyk picture sahithreddyk  路  3Comments

yahorsi picture yahorsi  路  3Comments

jzabroski picture jzabroski  路  3Comments

matty-hall picture matty-hall  路  3Comments