Changes between Version 2 and Version 3 of Contribute
- Timestamp:
- Mar 15, 2011, 12:40:05 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Contribute
v2 v3 2 2 [[PageOutline]] 3 3 4 = How to contribute to the CKEditor project = 4 = How to Contribute to the CKEditor Project = 5 There are several ways you can help CKEditor to become better software for yourself and to others. You can do that by: 5 6 6 There are several ways you can help CKEditor to become a better software to you and to others. You can do that by: 7 8 * [#Reportingbugs Reporting bugs]. 9 * [#Providingpatches Submitting patches]. 7 * [#Reportingbugs Reporting bugs] 8 * [#Providingpatches Submitting patches] 10 9 * [#Translating Translating] 11 * [#Documentation Writing] documentation .12 * Writing [http://docs.cksource.com/FCKeditor_3.x/Design_and_Architecture/Plugin_Based plugins] around CKEditor.13 * '''Helping''' others through our [http://cksource.com/forums/viewforum.php?f=10 support board] on forum.14 * '''Discussing''' on how CKEditor could be improved by posting on the [http://cksource.com/forums/viewforum.php?f=11 development board] onforum.10 * [#Documentation Writing] documentation 11 * Creating CKEditor [http://docs.cksource.com/FCKeditor_3.x/Design_and_Architecture/Plugin_Based plugins] 12 * '''Helping''' others through our [http://cksource.com/forums/viewforum.php?f=10 support board] on the community forum 13 * '''Discussing''' how CKEditor could be improved by posting on the [http://cksource.com/forums/viewforum.php?f=11 development board] of the community forum. 15 14 16 15 == Reporting bugs == 17 16 Described [wiki:Bugs here]. 17 18 18 == Providing patches == 19 We love patches, but several rules must be followed in order for them to be accepted: 19 20 20 We do love patches, but several rules must be followed to may them been efficiently accepted: 21 Following CKEditor [wiki:CodingStyle coding standards] is the easiest way for everybody to understand your code and get it accepted without changes and unnecessary delay. 21 22 22 === Providing patches === 23 Inside a patch, following [wiki:CodingStyle coding standards] is one of the easiest way for everybody to understand everybody's code and require no housekeeping. 23 Patch files are the official way to present your contribution. All patches should always be in the [http://en.wikipedia.org/wiki/Diff unified diff] format and stick to the conventions described [wiki:TicketLifeCycle#ProposingPatches here]. 24 24 25 Patch files are the official way to present us your contribution, it should always be in the [http://en.wikipedia.org/wiki/Diff unified diff] format and apply to the convention described [wiki:TicketLifeCycle#ProposingPatches here].25 Do not put the patch in the ticket description or comment unless it is a single line patch. Otherwise it is always better to attach a separate patch file. 26 26 27 Please don't put the patch in the ticket description or comment, unless it's a single line patch.27 Each patch should contain the code required to fix a problem or add a new feature, and may include relevant test case(s) to verify the result. Try to avoid addressing other irrelevant problems in it. 28 28 29 The patch should dedicate to code required to fix a problem or add a feature, may include relevant test case(s) to verify the result, and that should be all of it, avoid trying to address other irrelevant problems in it.29 If the code associated with a patch adds a new feature, or modifies the behavior of an existing feature, the patch should also contain documentation. 30 30 31 If the code associated with a patch adds a new feature, or modifies behavior of an existing feature, the patch should also contain documentation. 31 To ensure the high quality of the project code base we only grant repository commit permissions to core developers. For community contributors it is enough to add ''''HasPatch'''' to the '''keyword''' ticket field, and let the core developers take care of integrating the patch into the [wiki:TicketLifeCycle workflow]. 32 Depending on the review result your patch may finally get accepted and get committed, or you may choose to come with a new patch in case the review fails. 32 33 33 To make sure the quality of project, we only open repository commit permission for core developers, as a community contributors, it's enough to add ''''HasPatch'''' to the '''keyword''' ticket field, and let the core developers take care of the integration it into the [wiki:TicketLifeCycle workflow]. 34 Depending on the review result, your patch may finally get accepted and get committed, or you may choose to come with a new patch in case the review fails.34 == Translating == 35 CKEditor interface can be fully localized. Our language files are managed just like all other source files and you can find them in the [http://dev.ckeditor.com/browser/CKEditor/trunk/_source/lang lang] directory of the CKEditor installation package. If you would like to supplement or improve any of the language files as well as create a new localization, create a ticket and attach a patch with your changes. 35 36 36 === Translating === 37 38 Our language files are managed as other source files, you can find them in the [http://dev.fckeditor.net/browser/CKEditor/trunk/_source/lang lang] directory. 39 40 === Documentation === 41 42 Our documentation is composed in English, you're welcomed to write in the project's documentation site with an [http://docs.cksource.com/index.php?title=Special:UserLogin&type=signup&returnto=CKEditor_3.x/Developers_Guide account]. 37 == Documentation == 38 Our documentation is composed in English. You are welcome to add your comments to the '''Talk''' pages at the official documentation site with an [http://docs.cksource.com/index.php?title=Special:UserLogin&type=signup&returnto=CKEditor_3.x/Developers_Guide account]. If you would like to contribute some additional documentation resources (tutorials, use cases, code documentation), please contact us first.
