Our project welcomes external contributions. If you have an itch, please feel free to scratch it.
To contribute code or documentation, please submit a FIXME pull request.
A good way to familiarize yourself with the codebase and contribution process is to look for and tackle low-hanging fruit in the FIXME issue tracker. Before embarking on a more ambitious contribution, please quickly get in touch with us.
Note: We appreciate your effort, and want to avoid a situation where a contribution requires extensive rework (by you or by us), sits in backlog for a long time, or cannot be accepted at all!
If you would like to implement a new feature, please FIXME raise an issue before sending a pull request so the feature can be discussed. This is to avoid you wasting your valuable time working on a feature that the project developers are not interested in accepting into the code base.
If you would like to fix a bug, please FIXME raise an issue before sending a pull request so it can be tracked.
The project maintainers use LGTM (Looks Good To Me) in comments on the code review to indicate acceptance. A change requires LGTM from one of the maintainers.
For a list of the maintainers, see the MAINTAINERS.md page.
Each source file must include a license header for Eclipse Public License 2.0 Using the SPDX format is the simplest approach. e.g.
/*
© Copyright IBM Corporation 2022. All Rights Reserved.
SPDX-License-Identifier: EPL-2.0
*/
We have tried to make it as easy as possible to make contributions. This applies to how we handle the legal aspects of contribution. We use the same approach - the Developer's Certificate of Origin 1.1 (DCO) - that the Linux® Kernel community uses to manage code contributions.
We simply ask that when submitting a patch for review, the developer must include a sign-off statement in the commit message.
Here is an example Signed-off-by line, which indicates that the submitter accepts the DCO:
DCO 1.1 Signed-off-by: Random J Developer <random@developer.org>
You can include this automatically when you commit a change to your local git repository using the following command:
git commit -s
Other tips:
- How to create signature verification
- To configure your Git client to sign commits by default for a local repository, in Git versions 2.0.0 and above, run:
git config commit.gpgsign true
. - To sign all commits by default in any local repository on your computer, run:
git config --global commit.gpgsign true
.
Please feel free to connect with us via email: eimantas.pelikis@lt.ibm.com
-
Install dependencies:
yarn install
-
Create local config file (local.env) from the template (local.env.template)
-
Run app in watch mode (restarts on source changes):
yarn watch
Ignore the "[DEP0128] DeprecationWarning: Invalid 'main' field" when you run app in watch mode.
Note that
yarn compile
is designed to build source for production and one-time testing of your runtime. Don't forget to clean your workspace withyarn clean
afterwards.
Create a new Node.js debug configuration, add -r ts-node/register
and -r dotenv/config
to node args and move the program to the args list (so VS Code doesn't look for outFiles). For example:
{
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug Local",
"env": {
"DOTENV_CONFIG_PATH": "local.env"
},
"runtimeArgs": [
"-r",
"ts-node/register",
"-r",
"dotenv/config"
],
"args": [
"${workspaceFolder}/src/index.ts"
]
}]
}
-
You are welcome to propose a testing framework for Unit testing;
-
For SOE E2E testing we Bot Framework Emulator and access the local Bot instance on this endpoint:
http://localhost:3978/api/messages
Note that this is a mono-repo setup, which contains multiple packages managed by yarn
workspaces and lerna
.
- We use strict TypeScript types, so
any
declaration is allowed;
More guidelines are coming in the near future.
© Copyright IBM Corporation 2022. All Rights Reserved.