For contributing to the github repository i.e. making a PR in the Azure sentinel Reposiroty: https://github.com/Azure/Azure-Sentinel is it necessary to become a Microsoft partner or I can directly contribute without doing so?
The README of that repository contains a contributing section:
Contributing
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode#microsoft.com with any additional questions or comments.
For information on how to contribute, refer to the "how to contribute" guide on the project's wiki.
It is not necessary to be a Microsoft partner to contribute. You simply need to accept Microsoft's CLA (Contributor License Agreement). Send a PR and follow the instructions of the bot there, it will tell you how to proceed.
Related
When I tried to download load runner free trial its asking for business email. how to download the setup?
This is an issue you need to take up with Microfocus. Keep in mind the license for the evaluation version is not for production use.
As a commercial tool, the vendor expects that at the end of your trial, if the tool meets your needs that you will have the means to purchase it. They6 will want to have salespeople follow up. Having a public email prevents that type of activity in most cases.
I've been using VS Code for a year or so now. I have no idea how VS Code Extension security is handled.
I'm alarmed by things like this:
Markdown Preview Enhanced (927K+ downloads)
Markdown Preview Enhanced (fork that points to the original repo) (2k+ downloads)
Some questions I have are:
What does Microsoft do to ensure Extensions we install are safe?
Are they scanning the Extensions for known vulns?
Is VS Code safe to use in an Enterprise Environment?
How can I tell?
Why are duplicate extension names allowed!
There are security and marketing implications by Microsoft allowing "package-squatting".
Does anyone have insights to share regarding VS Code Extension Security?
Hm. Unfortunately, the link to "extension marketplace terms" that #jonrsharpe provided does not include the word "extension". If you extrapolate VS Code Extensions to be covered by the Azure Marketplace terms (as alluded to in the text), then you get this little tidbit:
https://azure.microsoft.com/en-us/support/legal/marketplace-terms/
Publisher Privacy Policies. Publishers are responsible for providing
privacy statements that describe their privacy practices with respect
to Customer Data collected by their Offerings or any customer
information that they receive from Microsoft. Unless indicated
otherwise in connection with a Marketplace Offering published by
Microsoft, Microsoft’s privacy, security, and data location and data
retention policies will not apply to any Marketplace Offering or to
Publishers’ use of any Customer Data or other customer information.
In short "...Microsoft's privacy, security...policies will not apply to any..." VS Code Extensions OR to "...Publishers' use of any Customer Data or other customer information."
Microsoft does NOT handle VS Code Extension Security.
We're starting a new development project using on-premise TFS 2018, git and Visual Studio. In the past we've followed the Agile model of creating epics and user stories and putting the requirements/ui mockups and other details directly in the user stories.
After living through that approach, we don't want go back down that road for the following reasons:
1) Once that feature is shipped, it becomes extremely difficult to locate the info. Who remembers what feature was done in what user story?
2) No centralized place to store feature documentation. Of course, we all don't want take the waterfall approach of spending 2 years writing feature requirements, but there is something to be said of having a centralized place organized by feature area that contains the relevant documentation.
3) Have you ever tried to read an extensive user story with requirements acceptance testing through either the web interface or through Visual Studio? It gets old pretty fast having to read through a 8 line window.
What we would like to do is do a hybrid of documentation and reference a link to the doc in the user story. The user story exists for sprint tracking, but the details are stored in the document. After the feature/user story has shipped, we can refer to the doc.
Therefore the question becomes how to store this type of info in TFS and link to it so it can open with a link in the user story. We know we can do this with SharePoint, but is it possible to do in on-premise TFS?
Currently, this is not directly possible in TFS with outgoing with some 3rd party vendors like Modernrequirements which will be paid services.
You could always use the CMMI template which is used for creating and managing requirement Workitems, but not for storing a huge set of requirements as you typically stored in requirement documents.
As you mentioned there are other ways like Storing the documents in
SharePoint, one drive etc., and link to the user stories
Creating a
markdown
in the user stories itself.
Check-in those documents in the version control(Git,TFVS)
Refer to this similar SO in order to understand it better.
After initial browsing in Google, I couldn't work out the scope of DocuSign API.
I would like to know if it's feasible to implement these features
Multiple templates with custom form fields
Assign workflow to templates - multi-user e-signing by stages?
automate e-signing internally
User management/privileges - to create new document, recall/cancel, etc
Manage List of recipients - type association
Reporting such as; number of documents signed in the last month,
Please briefly explain what is DocuSign capable of and what needs to be developed differently
Thanks in advance
The general answer to your question is "yes." The DocuSign website, Developer Center, and Signature API reference documentation can help you understand the DocuSign Signature product and APIs.
If you have additional questions, you can talk with DocuSign staff, or try it for yourself. The Developer center enables you to create a free developer sandbox.
For API issues, you can also ask questions here on StackOverflow. Note that your questions should be much more specific than the questions you listed above. You also should show what you have already tried and what is not working for you.
Currently I have an GitHub repo that I use for collaboration. I want anyone to be able to join it.
GitHub currently requires users to first find me (there is no form to request) and ask me and then they are mailed an invitation which they then have to accept.
I'm guessing there is an app out there for this but I can't find it.
I'm looking for either an integration that takes a turns a issue comment into a team add, or form the user can request an invite from.
Forking a repo remains the official way to contribute without asking. Then the contributor can make a pull request back to the original repo.
The goal is to "manage" (through PR review) the flow of contribution.
The other alternative would be to add several people owner of an organization team: that way, you would be the only one people would have to ask in order to be collaborators.
If this is an organization that you're trying to add members to, there is already some automation around that.
JazzBand allows anyone to join the organization. Their website uses the same mechanisms as add-to-org to add people to an organization.
Looking at their source code, it appears both use the GitHub API to add members to an organization.
PUT /orgs/:org/memberships/:username
That said, if this is a personal repository, you'll instead want to follow the API to add a collaborator
PUT /repos/:owner/:repo/collaborators/:username
It's likely you could modify either of those projects to fit this need. Cheers!