DoneJS StealJS jQuery ++ FuncUnit DocumentJS
3.0.0
2.3.27

 

  • Github
  • Twitter
  • Chat
  • Forum
  • Guides
    • introduction
      • Mission
      • Technical Highlights
      • Who uses CanJS?
    • experiment
      • Chat Guide
      • TodoMVC Guide
      • ATM Guide
      • Setting up CanJS
    • commitment
      • API Guide
      • Examples
      • Roadmap
      • Migrating to 3.0
    • contribute
      • Bug Report
      • Code
      • Documentation
      • Evangelism
      • Feature Suggestion
      • Releases
  • Core
  • Ecosystem
  • Infrastructure
  • Legacy
  • Bitovi
    • Bitovi.com
    • Blog
    • Consulting
    • Training
    • Open Source
  • Chat
  • Forum
  • Star
  • Follow @canjs
  • CanJS
  • /
  • Guides
  • /
  • Feature Suggestion
  • / On this page
    • Feature Suggestion

      page

      Learn how to suggest a feature.

      • source

      Overview

      CanJS uses Github Issues to track feature requests. However, CanJS is made up of many individual github repositories. Ideally, features are created within the repository whose code needs to be modified. For example, features with can-define can be created at canjs/can-define/issues/new.

      If you do not know which repository your feature belongs to, that's totally ok! Please create your issue in the main canjs/canjs issues page. The core team will move the issue to the correct repository if necessary.

      When creating an feature issue, it's very helpful to include:

      • Examples of what using the feature will look like.
      • Benefits and drawbacks of the feature.
      • Why the feature is important.
      • Any implementation details around the feature.

      Here's some example well written feature requests:

      • Make events fire asynchronously and dispatched during request animation frame or setImmediate
      • Modify key -> argument behavior in stache

      Also, please search for previous feature requests. If there's something similar, add to that, or give it a +1.

      Finally, if there are any questions, reach out to us on the CanJS forums or talk to us on the Gitter canjs/canjs channel.

      Priority, Tags, and Complexity

      The core team reviews issues and assigns them a P0 to P4 tag corresponding to the following priorities:

      • P0 - An issue that will preempt any other issues currently being worked on.
      • P1 - A critical feature or bug that needs to be fixed to keep CanJS's high degree of quality.
      • P2 - A feature or bug that is less likely to be encountered, but something we intend to get to.
      • P3 - A nice to have. The OS team might get to it, but it's helpful if the community assists.
      • P4 - A nice to have that the OS team will accept, but will be unlikely to prioritize any effort towards.

      There are several ways to influence these priorities:

      • Offer to pair with a contributor on a solution.
      • Write a good test.
      • Come to a DoneJS Contributors meeting and make your case.
      • Get others from other organizations to +1 the issue.
      • Make your case on gitter with a contributor or in the issue.
      • You can always hire Bitovi or a contributor to make the change.

      Also, the core team will often include a complexity indicator in the title that looks like ~NUMBER. This is a fibonacci number. ~1 means its an extremely simple task. ~8 is about a half day task. ~34 might take a week of experimentation.

      CanJS is part of DoneJS. Created and maintained by the core DoneJS team and Bitovi. Currently 3.0.0.