/cspec

DEPRECATED - Community Specifications & Proposals

Community Specifications & Proposals (CSPEC)

This is the Appcelerator Community Specifications and Proposals repository.

Pending Proposals

  • CSPEC-1 Titanium Multithreading support
  • CSPEC-2 Unified appc.js file format
  • CSPEC-3 Titanium Hyperloop Modules
  • CSPEC-4 Titanium support for Package(r)s

How to submit a CSPEC

We welcome a CSPEC from anyone in the community and encourage you to submit it. Please follow these guidelines:

  • If you are not an employee or contractor of Appcelerator, please make sure you have a valid Contributors License Agreement (CLA) in place before submitting a CSPEC. You can digitally sign the CLA online. Please indicate your email address in your first pull request so that we can make sure that will locate your CLA. Once you've submitted it, you no longer need to send one for subsequent submissions.
  • Please use the CSPEC template when creating your CSPEC repository. You can copy this file into your repo and rename this file README.md. Make sure you don't assign a CSPEC number when submitting, we will assign one once it is added to the repo officially. Make sure you write your CSPEC in English (primarily), although you're welcome to translate it in a separately named document such as README-fr.md.
  • Your repository must be public and you should name the repository using the following convention: cspec-<product>-<short_title>.
  • Open a issue in this repository with the URL to your CSPEC repo. Once we validate your CLA, we will update the CSPEC listing with a link to your repo.
  • Publicize your CSPEC on various social media and other locations where AppC community congregate to get input and feedback!

Best Practices

Here are some best practice guidelines when writing a CSPEC:

  • Since your CSPEC is a git repository, you should add test cases, example application code, etc. to your proposal. This will help make sure we have good examples of use cases as well as communicate to implementers, quality engineers, documentation team, etc. information about what is being implemented.
  • When writing a CSPEC, try and provide good examples of the problem and/or use cases to help illustrate the need
  • If there are open / unresolved issues, create a section listing them for feedback and resolution
  • Link to other resources (documentation, references, etc.) and don't always assume the reader knows or can find them. Make it easy for them.
  • Make sure the CSPEC is narrowly focused around a specific API, etc. Broad brush features or suggestions will not be helpful or approved for consideration. The goal for the CSPEC is to provide enough detail to discuss and debate and if approved, then to implement, test and document.

Legal Stuff

These proposals are non-binding and may not be implemented, may be implemented partially, differently or not at all. Any intellectual property developed as part of these proposals are owned and Copyright © 2015 by Appcelerator, Inc. All Rights Reserved.