{"action":"created","issue":{"url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/1055","repository_url":"https://api.github.com/repos/nodemcu/nodemcu-firmware","labels_url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/1055/labels{/name}","comments_url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/1055/comments","events_url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/1055/events","html_url":"https://github.com/nodemcu/nodemcu-firmware/issues/1055","id":133777365,"number":1055,"title":"Contributing to NodeMCU","user":{"login":"TerryE","id":690173,"avatar_url":"https://avatars.githubusercontent.com/u/690173?v=3","gravatar_id":"","url":"https://api.github.com/users/TerryE","html_url":"https://github.com/TerryE","followers_url":"https://api.github.com/users/TerryE/followers","following_url":"https://api.github.com/users/TerryE/following{/other_user}","gists_url":"https://api.github.com/users/TerryE/gists{/gist_id}","starred_url":"https://api.github.com/users/TerryE/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TerryE/subscriptions","organizations_url":"https://api.github.com/users/TerryE/orgs","repos_url":"https://api.github.com/users/TerryE/repos","events_url":"https://api.github.com/users/TerryE/events{/privacy}","received_events_url":"https://api.github.com/users/TerryE/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/labels/governance","name":"governance","color":"207de5"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":13,"created_at":"2016-02-15T17:48:31Z","updated_at":"2016-02-19T01:39:18Z","closed_at":null,"body":"This is a general discussion about the current [CONTRIBUTING.md](nodemcu/nodemcu-firmware/blob/dev/CONTRIBUTING.md) with the aim of exploring the contributor consensus before suggesting any amendments. I feel that this needs some further enhancements, as there are a number of classes of contribution, and rules for contribution vary for these classes:\r\n\r\n1.   **Bugfixes and corrections to the Documentation**.  Trivial ones can be made with a simple PR as per the process described, but the comment should clearly explain the reason for the change, preferably with an example of the failure mode. \r\n\r\n    Non-trivial bugfixes should first be raised as an issue, together with an explanation of the bug and at least one reproducible test case which demonstrates the bug.  If the originator is proposing to implement bugfix, then this should be made clear in the post, and possibly including a quick sketch of the proposed solution.  This will allow more experienced contributors to comment before the poster carries out potentially wasted effort.\r\n2.  **New library modules** to support extra hardware, etc. We need a new construction guideline covering these (which I discuss below), but in general any developed library which conforms to this guideline will be accepted by the project, so long as: \r\n    - The module achieves a materiality test: that is the module meets a need that many ESP8266 Lua developers will find useful.  It is recommend that the originator raise an issue describing the reasoning behind the module and implementation approach.\r\n   - The originator has provided evidence that the module has been adequately tested as a category (4) person module.\r\n   - At least one other committer or regular contributor has put the module to use (e.g. with the target hardware).  My reasoning for this test is that this gives us some independent verification of the resilience of the module, and if no one volunteers to do this then it really fails the materiality test.\r\n\r\n3.  **Modifications to the core firmware**.  This includes the Lua system, it's platform abstraction and any core modules that are commonly used in builds, including string, table, coroutine, math, debug, node, file, tmr, wifi, net, gpio, uart, pmw, ow, i2c, spi. Other than specifically scoped bufixes, this is not something that we should consider lightly and therefore unless there is a demonstrated benefit.  An issue _must_ first be raised to discuss the potential advantages; describe the functional change; provide the scope of the modification; define the test strategy; and determine any potential backwards incompatibility.  If the propose is not from a committer or establish contributor, then one of these must volunteer to work with the originator during the development process.\r\n\r\n4.  _**Local modules and customisation**.  As this is an Open source project, any user is free to add modules and modifications to meet their own needs.  But such modules are not the business of this project, and any construction guidelines or materiality tests are only informative for the developer._\r\n\r\nI would like to explore some of the issues relating to specific categories in later comments, but I just want to test the consensus to this analysis so far, first. "},"comment":{"url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/comments/186006593","html_url":"https://github.com/nodemcu/nodemcu-firmware/issues/1055#issuecomment-186006593","issue_url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/1055","id":186006593,"user":{"login":"devyte","id":16824838,"avatar_url":"https://avatars.githubusercontent.com/u/16824838?v=3","gravatar_id":"","url":"https://api.github.com/users/devyte","html_url":"https://github.com/devyte","followers_url":"https://api.github.com/users/devyte/followers","following_url":"https://api.github.com/users/devyte/following{/other_user}","gists_url":"https://api.github.com/users/devyte/gists{/gist_id}","starred_url":"https://api.github.com/users/devyte/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/devyte/subscriptions","organizations_url":"https://api.github.com/users/devyte/orgs","repos_url":"https://api.github.com/users/devyte/repos","events_url":"https://api.github.com/users/devyte/events{/privacy}","received_events_url":"https://api.github.com/users/devyte/received_events","type":"User","site_admin":false},"created_at":"2016-02-19T01:39:18Z","updated_at":"2016-02-19T01:39:18Z","body":"How about three levels: \r\n\"core\": modules like file, wifi, uart, etc.\r\n\"utils\": modules like crypto, http, ringbuffer, etc.\r\n\"drivers\": modules for specific peripherals, like LCDs and sensors (many users don't need these)\r\n\r\nMaybe one last one:\r\n\"universe\" or \"user\" or \"misc\": modules which have a very small user base, but have been accepted because they're good or useful. This last means, of course, that there is agreement that the module is not of the \"stack it high sell it cheap\" variety :)\r\n\r\nAnyways, just an idea."}}