Skip to content

Commit a07f80b

Browse files
committed
part 24
1 parent 0cbb1e5 commit a07f80b

8,755 files changed

Lines changed: 1224925 additions & 2543822 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

CHANGELOG.md

Lines changed: 1189 additions & 0 deletions
Large diffs are not rendered by default.

CODE_OF_CONDUCT.md

Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
# NativeScript Community Code of Conduct
2+
3+
Our community members come from all walks of life and are all at different stages of their personal and professional journeys. To support everyone, we've prepared a short code of conduct. Our mission is best served in an environment that is friendly, safe, and accepting; free from intimidation or harassment.
4+
5+
Towards this end, certain behaviors and practices will not be tolerated.
6+
7+
## tl;dr
8+
9+
- Be respectful.
10+
- We're here to help.
11+
- Abusive behavior is never tolerated.
12+
- Violations of this code may result in swift and permanent expulsion from the NativeScript community channels.
13+
14+
## Contact
15+
16+
- support@nativescript.org
17+
18+
## Scope
19+
20+
We expect all members of the NativeScript community, including administrators, users, facilitators, and vendors to abide by this Code of Conduct at all times in our community venues, online and in person, and in one-on-one communications pertaining to NativeScript affairs.
21+
22+
This policy covers the usage of the NativeScript Slack community, as well as the NativeScript support forums, NativeScript GitHub repositories, the NativeScript website, and any NativeScript-related events. This Code of Conduct is in addition to, and does not in any way nullify or invalidate, any other terms or conditions related to use of NativeScript.
23+
24+
The definitions of various subjective terms such as "discriminatory", "hateful", or "confusing" will be decided at the sole discretion of the NativeScript administrators.
25+
26+
## Friendly, Harassment-Free Space
27+
28+
We are committed to providing a friendly, safe, and welcoming environment for all, regardless of gender identity, sexual orientation, disability, ethnicity, religion, age, physical appearance, body size, race, or similar personal characteristics.
29+
30+
We ask that you please respect that people have differences of opinion regarding technical choices, and acknowledge that every design or implementation choice carries a trade-off and numerous costs. There is seldom a single right answer. A difference of technology preferences is never a license to be rude.
31+
32+
Any spamming, trolling, flaming, baiting, or other attention-stealing behaviour is not welcome, and will not be tolerated.
33+
34+
Harassing other users of NativeScript is never tolerated, whether via public or private media.
35+
36+
Avoid using offensive or harassing package names, nicknames, or other identifiers that might detract from a friendly, safe, and welcoming environment for all.
37+
38+
Harassment includes, but is not limited to: harmful or prejudicial verbal or written comments related to gender identity, sexual orientation, disability, ethnicity, religion, age, physical appearance, body size, race, or similar personal characteristics; inappropriate use of nudity, sexual images, and/or sexually explicit language in public spaces; threats of physical or non-physical harm; deliberate intimidation, stalking or following; harassing photography or recording; sustained disruption of talks or other events; inappropriate physical contact; and unwelcome sexual attention.
39+
40+
## Acceptable Content
41+
42+
The NativeScript administrators reserve the right to make judgement calls about what is and isn't appropriate in published content. These are guidelines to help you be successful in our community.
43+
44+
Content must contain something applicable to the previously stated goals of the NativeScript community. "Spamming", that is, publishing any form of content that is not applicable, is not allowed.
45+
46+
Content must not contain illegal or infringing content. You should only publish content to NativeScript properties if you have the right to do so. This includes complying with all software license agreements or other intellectual property restrictions. For example, redistributing an MIT-licensed module with the copyright notice removed, would not be allowed. You will be responsible for any violation of laws or others’ intellectual property rights.
47+
48+
Content must not be malware. For example, content (code, video, pictures, words, etc.) which is designed to maliciously exploit or damage computer systems, is not allowed.
49+
50+
Content name, description, and other visible metadata must not include abusive, inappropriate, or harassing content.
51+
52+
## Reporting Violations of this Code of Conduct
53+
54+
If you believe someone is harassing you or has otherwise violated this Code of Conduct, please contact the administrators and send us an abuse report. If this is the initial report of a problem, please include as much detail as possible. It is easiest for us to address issues when we have more context.
55+
56+
## Consequences
57+
58+
All content published to the NativeScript community channels is hosted at the sole discretion of the NativeScript administrators.
59+
60+
Unacceptable behavior from any community member, including sponsors, employees, customers, or others with decision-making authority, will not be tolerated.
61+
62+
Anyone asked to stop unacceptable behavior is expected to comply immediately.
63+
64+
If a community member engages in unacceptable behavior, the NativeScript administrators may take any action they deem appropriate, up to and including a temporary ban or permanent expulsion from the community without warning (and without refund in the case of a paid event or service).
65+
66+
## Addressing Grievances
67+
68+
If you feel you have been falsely or unfairly accused of violating this Code of Conduct, you should notify the administrators. We will do our best to ensure that your grievance is handled appropriately.
69+
70+
In general, we will choose the course of action that we judge as being most in the interest of fostering a safe and friendly community.
71+
72+
## Contact Info
73+
Please contact Dan Wilson @DanWilson if you need to report a problem or address a grievance related to an abuse report.
74+
75+
You are also encouraged to contact us if you are curious about something that might be "on the line" between appropriate and inappropriate content. We are happy to provide guidance to help you be a successful part of our community.
76+
77+
## Credit and License
78+
79+
This Code of Conduct borrows heavily from the WADE Code of Conduct, which is derived from the NodeBots Code of Conduct, which in turn borrows from the npm Code of Conduct, which was derived from the Stumptown Syndicate Citizen's Code of Conduct, and the Rust Project Code of Conduct.
80+
81+
This document may be reused under a Creative Commons Attribution-ShareAlike License.

CONTRIBUTING.md

Lines changed: 139 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,139 @@
1+
# Contributing to NativeScript
2+
3+
## Before You Start
4+
5+
Anyone wishing to contribute to the NativeScript project MUST read & sign the [NativeScript Contribution License Agreement](http://www.nativescript.org/cla). The NativeScript team cannot accept pull requests from users who have not signed the CLA first.
6+
7+
## Introduction
8+
9+
These guidelines are here to facilitate your contribution and streamline the process of getting changes merged into this project and released. Any contributions you can make will help tremendously, even if only in the form of an issue report. Following these guidelines will help to streamline the pull request and change submission process.
10+
11+
## Reporting Bugs
12+
13+
1. Always update to the most recent master release; the bug may already be resolved.
14+
2. Search for similar issues in the issues list for this repo; it may already be an identified problem.
15+
3. If this is a bug or problem that is clear, simple, and is unlikely to require any discussion -- it is OK to open an issue on GitHub with a reproduction of the bug including workflows and screenshots. If possible, submit a Pull Request with a failing test, entire application or module. If you'd rather take matters into your own hands, fix the bug yourself (jump down to the "Code Fixes and Enhancements" section).
16+
17+
## Requesting New Features
18+
19+
1. Use Github Issues to submit feature requests.
20+
2. First search for a similar request and extend it if applicable. This way it would be easier for the community to track the features.
21+
2. When a brand new feature requested, try to give as many details on your need as possible. We prefer that you explain a need than explain a technical solution for it. That might trigger a nice conversation on finding the best and broadest technical solution to a specific need.
22+
23+
## Asking for Help
24+
25+
-------------The NativeScript team does *not* provide guaranteed formal support, except to those customers who have purchased a [commercial license for AppBuilder](http://www.telerik.com/platform) (Professional, Enterprise, etc.) or a support-only package from Telerik.com. Please do not create support requests for this project in the issues list for this repo, as these will be immediately closed and you'll be directed to post your question on a community forum.
26+
27+
## Code Fixes and Enhancements
28+
29+
### 1. Log an Issue
30+
31+
Before doing anything else, we ask that you file an issue in the Issues list for this project. First, be sure to check the list to ensure that your issue hasn't already been logged. If you're free and clear, file an issue and provide a detailed description of the bug or feature you're interested in. If you're also planning to work on the issue you're creating, let us know so that we can help and provide feedback. To help us investigate your issue and respond in a timely manner, you can provide is with the following details:
32+
- **Overview of the issue**: Provide a short description of the visible symptoms. If applicable, include error messages, screen shots, and stack traces.
33+
- **Motivation for or use case**: Let us know how this particular issue affects your work.
34+
- **Telerik NativeScript version(s)**: List the current version and build number of the CLI interface, the runtime and the modules. You can get these by checking the package.json files of the respective package. Let us know if you have not observed this behavior in earlier versions and if you consider it a regression.
35+
- **System configuration**: Provide us with relevant system configuration information such as operating system, network connection, proxy usage, etc. Let us know if you have been able to reproduce the issue on multiple setups.
36+
- **Steps to reproduce**: If applicable, submit a step-by-step walkthrough of how to reproduce the issue.
37+
- **Related issues**: If you discover a similar issue in our archive, give us a heads up - it might help us identify the culprit.
38+
- **Suggest a fix**: You are welcome to suggest a bug fix or pinpoint the line of code or the commit that you believe has introduced the issue.
39+
40+
### 2. Fork and Branch
41+
42+
#### Fork Us, Then Create A Topic Branch For Your Work
43+
44+
The work you are doing for your pull request should not be done in the master branch of your forked repository. Create a topic branch for your work. This allows you to isolate the work you are doing from other changes that may be happening.
45+
46+
Github is a smart system, too. If you submit a pull request from a topic branch and we ask you to fix something, pushing a change to your topic branch will automatically update the pull request.
47+
48+
#### Isolate Your Changes For The Pull Request
49+
50+
See the previous item on creating a topic branch.
51+
52+
If you don't use a topic branch, we may ask you to re-do your pull request on a topic branch. If your pull request contains commits or other changes that are not related to the pull request, we will ask you to re-do your pull request.
53+
54+
#### Branch from "master"
55+
56+
The "master" branch of the NativeScript repository is for continuous contribution. Always create a branch for your work from the "master" branch. This will facilitate easier pull request management.
57+
58+
#### Contribute to the Code Base
59+
Before you submit a Pull Request, consider the following guidelines.
60+
61+
Search GitHub for an open or closed Pull Request that relates to your submission.
62+
Clone the repository.
63+
```bash
64+
git clone git@github.com:NativeScript/android-runtime.git
65+
```
66+
Make your changes in a new git branch. We use the Gitflow branching model so you will have to branch from our master branch.
67+
```bash
68+
git checkout -b my-fix-branch master
69+
```
70+
Create your patch and include appropriate test cases.
71+
Build your changes locally.
72+
```bash
73+
grunt
74+
```
75+
Commit your changes and create a descriptive commit message (the commit message is used to generate release notes).
76+
```bash
77+
git commit -a
78+
```
79+
Push your branch to GitHub.
80+
```bash
81+
git push origin my-fix-branch
82+
```
83+
In GitHub, send a Pull Request to NativeScript:android-runtime:master.
84+
If we suggest changes, you can modify your branch, rebase, and force a new push to your GitHub repository to update the Pull Request.
85+
```bash
86+
git rebase master -i
87+
git push -f
88+
```
89+
That's it! Thank you for your contribution!
90+
91+
When the patch is reviewed and merged, you can safely delete your branch and pull the changes from the main (upstream) repository.
92+
93+
Delete the remote branch on GitHub.
94+
```bash
95+
git push origin --delete my-fix-branch
96+
```
97+
Check out the master branch.
98+
```bash
99+
git checkout master -f
100+
```
101+
Delete the local branch.
102+
```bash
103+
git branch -D my-fix-branch
104+
```
105+
Update your master branch with the latest upstream version.
106+
```bash
107+
git pull --ff upstream master
108+
```
109+
110+
#### Squash your commits
111+
112+
When you've completed your work on a topic branch, we prefer that you squash your work down into a single commit to make the merge process easier. For information on squashing via an interactive rebase, see [the rebase documentation on GitHub](https://help.github.com/articles/interactive-rebase)
113+
114+
### 3. Submit a Pull Request
115+
116+
See [Github's documentation for pull requests](https://help.github.com/articles/using-pull-requests).
117+
118+
Pull requests are the preferred way to contribute to NativeScript. Any time you can send us a pull request with the changes that you want, we will have an easier time seeing what you are trying to do. But a pull request in itself is not usually sufficient. There needs to be some context and purpose with it, and it should be done against specific branch.
119+
120+
### Provide A Meaningful Description
121+
122+
Similar to reporting an issue, it is very important to provide a meaningful description with your pull requests that alter any code. A good format for these descriptions will include four things:
123+
124+
1. Why: The problem you are facing (in as much detail as is necessary to describe the problem to someone who doesn't know anything about the system you're building)
125+
126+
2. What: A summary of the proposed solution
127+
128+
3. How: A description of how this solution solves the problem, in more detail than item #2
129+
130+
4. Any additional discussion on possible problems this might introduce, questions that you have related to the changes, etc.
131+
132+
Without at least the first 2 items in this list, we won't have any clue why you're changing the code. The first thing we'll ask, then, is that you add that information.
133+
134+
## Code Style
135+
136+
We are currently using Eclipse to write code. We are using predefined code formating rules for C++ and Java:
137+
138+
* [C++](./CodingStyle.Cpp.xml)
139+
* [Java](./CodingStyle.Java.xml)

0 commit comments

Comments
 (0)