The NT documentation sites, forum and forge, and IRC channels have existed publicly for a long time. They provide a great deal of good information and are useful resources for our users to receive help and support their favorite content management system. We want to keep them that way. We started with few rules and expected that good behavior was just "understood". Unfortunately, we have learned over time that that is not always the case. This caused us to develop rules that help us to keep these tools the valuable resource they are, and to keep people wanting to come back. Today, we announce the collection of these rules in one place, with full descriptions. Please read this document in its entirety before you post anywhere on our sites. Reasoning The primary reason for this document is simple. Time is valuable. Your time is as valuable as ours. Though people generally enjoy contributing as they can, nobody enjoys having their time wasted. Secondarily, nobody enjoys visiting a website or contributing to a community where there is a lot of unnecessary noise, rudeness, immaturity, arguing, copyright infringement, or spam. Onus The onus is on each and every person using the NT communication channels to follow each and every rule and guideline. The owners and contributors to these websites have no responsibility to educate others on proper behavior. Failure to follow the rules can—and will—have consequences, including sanctions. Warnings for violating this code of conduct are not mandatory. Channels Note: All the rules and guidelines below apply equally whether posting publicly on the NT Forum, the Forge, IRC, documentation sites, or via the Private Message mechanism, or any communication mechanism provided by the NT dev team. Not following these rules may result in your requests being ignored, edited, moved, deleted, or further sanctions as specified below. 1. BE POLITE, BE PROFESSIONAL. As professionals we are expected to maintain a level of civility, maturity, politeness, and professionalism in our communications with our suppliers, employers, or customers. We also expect the same when others are communicating with us, or using our communication channels. a: Absolutely no profanity, flaming, personal attacks, YELLING, vulgarity, or rude behavior (see the registration agreement). b: No posting of copyrighted or illegal material without permission (see registration agreement). c: Act as if you are talking with a potential supplier, employer, or customer at all times. Maybe you are. d: If you have a concern or complaint to discuss, do it privately. e: If you absolutely feel it is appropriate to rant and complain publicly, do it elsewhere. We don't want to hear it. f: Behave professionally and maturely in all of your online endeavors. What you do on-line elsewhere may affect your treatment on our sites. We will not knowingly associate with individuals whose behavior outside of our site(s) is not civil, mature, polite and professional. Additionally, we will not knowingly associate in any way with individuals or groups that infringe copyrights or trademarks held by The Dev Team or others, impugn our brand or those of others. or imply an association with the Dev Team without an existing, valid authorization. 2. POST ONLY ISSUES RELATED TO NT SPECIFICALLY The NT communication channels are not channels to discuss last night's hockey game, the latest US presidential election, or even general IT and web development issues. Please keep all posts specifically related to CMS Made Simple, its plugins, add-on modules, and creating NT-powered websites. 3. RESEARCH BEFORE YOU POST Often, posts on the forum have been either answered clearly in the various documentation locations, or already answered numerous times. It is absolutely CRITICAL, in order to not waste your time or that of others; that you do your research before posting your question. There are numerous places and methods to research your problem. Some of them are: A: Questions relating to the NT core - The NT Documentation website, including the troubleshooting page and knowledge base section. - The default content pages, templates, and style-sheets distributed with NT - The help for installed tags available by clicking the 'help' link on each row in the Extensions >> Tags page of the NT admin console. - The help for installed modules available by clicking the 'help' link on each row in the Extensions >> Modules page of the NT admin console. - The Smarty documentation - The changelog that is updated for each released NT version in doc/CHANGELOG.txt B: For module/plugin/UDT development questions: - The help for installed tags available by clicking the 'help' link on each row in the Extensions >> Tags page of the NT admin console. - The help for installed modules available by clicking the 'help' link on each row in the Extensions >> Modules page of the NT admin console. - The module's changelog, which is usually updated with relevant information by the module developer(s) prior to each release. It is available by clicking on the 'about' link on each row in the Extensions >> Modules page of the NT admin console. C: Google, and search the forums Googling and searching the NT forum (you can even search the NT forum WITH Google) will often find the solution to your issues quickly and painlessly. Many people have wasted days waiting for answers to questions that could have been answered in minutes with Google. 4. POST IN THE PROPER BOARD. The Dev Team has divided the forum into numerous topical sections to assist people in quickly finding topical information, to allow people to communicate in their logical sections, and to assist the people that can reply to posts to find the posts that they may be able to reply to. 5. ONE QUESTION OR ISSUE PER POST. Do not post multiple questions (even if you think that they are related) in one post. This helps people who may be able to answer your questions to find them. 6. PROVIDE INFORMATION WHEN ENCOUNTERING A PROBLEM OR POSING A QUESTION. It is ABSOLUTELY MANDATORY that you provide sufficient information to be able to reproduce or understand your difficulty. Without information there is no chance that people will be able to understand or reproduce your difficulty in order to assist you. Therefore, you are wasting your time and the time of everybody that reads your post. Do: Review the forge for the applicable project (add-on or core) for existing bugs that may match your issue. Do: Post your system information (it is available by navigating to Extensions >> System Information in the NT admin panel) in the first post of every new thread. Do: Post links to pages that will illustrate the problem. and/or to screen captures. Do: Be verbose, use full sentences and paragraphs. Post specific examples, copy and paste error messages. NOTE: As part of doing your research you should have reviewed and understood all applicable error messages from the system when encountering a problem. Including those from the PHP error log, NT's debug mode, NT's Audit log, and the browser's javascript/network console. See the 'Knowledge base' and the 'Troubleshooting' pages of the NT Docs site for information. The troubleshooting page is available at: https://docs.cmsmadesimple.org/troubleshooting/tips and the knowledgebase is available at: https://docs.cmsmadesimple.org/troubleshooting/information-database. Do: Take some time to format your message so it is readable. Do Not: Wait for somebody to ask for information. Often if a potential responder has to ask for basic information, they will not respond at all. Providing too much information is better than not providing enough. Do Not: Threaten or attempt to intimidate potential responders. Saying things like I need this fixed today or I will move to Wordpress, or give you a bad review on Linkedin, will not help your cause. In fact, you will almost certainly receive a negative response or none at all. 7. NO DUPLICATE POSTS Posting the same question in multiple forums or, for example, posting your question in English, French, and the Russian forums just wastes your time and everybody else's. 8. HAVE PATIENCE Posts are answered by volunteers, in their spare time. It may be days before you get a response. Bumping your post too often is akin to a child jumping up and down and yelling, trying to get attention. It may get you attention, but it's probably not going to get you the attention you want. Lack of response to a thread typically indicates that people don't understand the problem you are having. You should consider more research and then revising your post. With an investment of more time, you may solve your own problem and be able to help others. 9. DO NOT RE-OPEN SOLVED, CLOSED OR OLD THREADS. It is fine to refer to a topic with a link, but do not reply to threads that are months or years old, and/or solved. This helps keep the signal to noise ratio high. People can find posts that are related to their version of the software. 10. DO NOT HIJACK POSTS. Add to a post only if you have valuable, related information to add. Likewise, posts which contain merely a +1 or -1 with no further information are not really contributing. 11. NO COMMERCIAL ADVERTISING Absolutely no commercial advertising on this board. Everybody is treated equally. If you would like to advertise, contact a site administrator for the current rates. [link: https://newstargeted.com/partners/advertising/] 12. NO DUPLICATE ACCOUNTS. One account per channel, per user. The only exception to this is that some Dev Team members will occasionally create additional accounts for the purposes of software or feature testing. If you were banned, for whatever reason, that is not justification to create another account. If you feel that the banning was in error, feel free to politely contact a site administrator via email. 13. DO NOT POST SOURCE CODE HACKS ON THE FORUM. Sometimes people post hacks or modifications to a module's source code or to the source code of the core in an effort to solve a problem or add a feature. The forum is not the proper place for these. Instead, see the section on contributing below. 14. NEW USER POSTS ARE SCREENED To minimize spam and to prevent those who want to criticize or attack by creating multiple accounts we have implemented a screening policy. The first 5 posts by a new account must be approved by a moderator before being visible to the community as a whole. Additionally, until those first posts are approved, you cannot communicate in the Private Message system. Support 15: SUPPORT IS A BONUS, NOT A RIGHT. CMS Made Simple, and all of its modules are distributed under the GNU Public License (v2). This is free (as in freedom) software, not necessarily free (as in cost). As part of the GNU Public License that is available on this website, and as part of the NT download and as part of the package downloaded for many third party modules. The GPL explicitly states that the product is distributed AS IS, without any warranty, or even the warranty of basic merchantability, and only in the hopes that it may be useful. As well, the developers accept no liability whatsoever for damages. This means that there is absolutely no obligation for support of the software. However, As professionals, we do enjoy seeing our work being used and try to be helpful where possible. 16: SUPPORT MAY OR MAY NOT BE FROM THE AUTHORS OR DEVELOPERS OF THE CODE. Often potential answers to your questions or problems may come from people who are users like you and not necessarily part of the core team or developers of third party modules. Show respect, professionalism, and maturity at all times. 16. NO SUPPORT FOR HACKED CORE OR ADD-ONS The GPLv2 (see above) gives you the freedom to use your programming abilities to modify the source code as you see fit. However, it is not fair to our community to ask them for assistance with difficulties after you have modified the source to fix bugs or add features. We cannot know without analyzing all of the code in its entirety (which is too much effort for technical support) what you have done, and what the complications of those changes are. The premise is, if you are skilled enough to hack the code to add functionality or fix bugs then you do not need technical assistance. We will not knowingly assist you with technical difficulties if you have hacked the source code. Keeping that information from your posts in the hopes of getting technical assistance is a violation of the rules in this document, and you may be subject to sanction. Bugs and Features 17: BUGS ARE REPRODUCIBLE, PROBLEMS ARE NOT NECESSARILY BUGS. ONLY POST BUGS ON THE FORGE. The forge includes functionality where users can report bugs. Bugs are reproducible software defects. Reporting a bug is an effort to contribute information to the software developer. It is not to be considered a direct line to the software developer for technical assistance. When reporting a bug you should be providing all of the information using all of the rules above, AND you MUST also include exact steps to allow the developer to reproduce, understand, and then potentially address the issue. You should attempt to isolate the issue as much as possible and provide the basic instructions that the developer can follow to reproduce the issue on THEIR environment. If a developer responds with 'Works for me' or alters your forge ticket to that status that indicates that given the information supplied the developer could not reproduce the issue that you are reporting, You then need to dig further to isolate the issue—perhaps by attempting to reproduce the issue on a different install on a different server. 18: FEATURE REQUESTS ARE TO BE WELL DESCRIBED AND DOCUMENTED. Just like problems or questions posted on the forum or bug reports on the forge, feature requests must be well described, well informed, polite, professional, and provide information. Feature requests should also include a well-described use case so that the developer can envision how you would like to use the software, and potentially be convinced to undertake the effort to include it. Contributing 19: SUBMITTING BUG FIX PATCHES FOR THE CORE OR THIRD PARTIES We wholeheartedly encourage you to submit fixes for bugs in released code in order to assist the developers of that project. Here are some guidelines: a: Use the latest released code, or the latest code from the source code repository (if available). b: Clearly describe the patch and the issue you are solving (see above wrt reporting bugs). Be verbose. c: Only submit your work in 'patch' format. You may need to Google and/or install some software to generate the appropriate file. d: Please try to keep posts small. If there is a serious change required it may be best to open up a discussion first. 20: CONTRIBUTING FEATURE PATCHES You are encouraged to discuss your proposed feature patch with the applicable developers before beginning work and posting it to the forge. This is because feature patches may be problematic for the related developers. Here are a few reasons: a: They may be incorrect, inefficient, buggy or in the wrong format. b: They may not coincide with the goals that the software developer has for the project. c: There are potential copyright and license issues to resolve. d: They can, and usually do, require the developer to accept the code as their own, and provide some support for them. At a minimum, they are obliged to maintain the feature(s) for some time. Therefore, the developer(s) on a project have no obligation to entertain feature or bug fix patches, or to accept them. And depending on the policy of that developer or team, they may delete them from the forge. 21: OPEN SOURCE SOFTWARE DEVELOPMENT IS NOT A DEMOCRACY. It is important to remember that open source software development is primarily done by volunteers, in their spare time. As mentioned above, the developers have no obligation to support their product, or to entertain feature requests. And even if a feature is considered highly desired, its implementation is ultimately the decision of the software developers and team involved in the project and those doing the work. A feature request, or even 1000 votes for a feature, in no way imposes an obligation on the developer to implement the feature. If you feel that a feature would be useful in the product then you may discuss the feature with the developers in an informed, polite, and mature manner. Your goal at this time is to convince the appropriate developers that they should donate more of their spare time to either implement the feature on their own or to review and accept your feature patch (see above). Just because a developer declines to implement your feature idea does not indicate that they are not listening. 22: WHEN TO DIRECTLY CONTACT A DEVELOPER. Note: It is generally considered rude to contact a developer via Skype, Google Hangouts, Facebook, Telephone etc. without prior approval. As a general rule, you should only contact a developer via the information available in their forum profile or as found in the help for a module. When you are encountering problems, and you feel that you have not received a satisfactory response for an issue you are having with the core or a module you may be inclined to contact a developer directly. This should be a last resort. If you do endeavor to contact a developer directly you should follow all of the rules above related to maturity and information in your post and also enquire about that developer's rates. As there is no obligation for support, and you are requesting the developer to spend some of their time assisting you, you should be prepared to compensate that developer for their time. If you are interested in contributing a feature patch to the core or a third party add-on then please feel free to contact the appropriate developer directly and engage in a discussion. Additionally, if you would like to financially sponsor a feature to an add-on then feel free to contact the developer directly, and open up a discussion with them regarding that feature. Most developers would be happy to engage in a conversation regarding the potential sponsorship of features and provide you with an estimate of time, availability, and costs. Similarly, it is possible to sponsor enhancements to the NT core. However, with the core, extra steps must be followed, including the Dev Team engaging in a vote that the proposed feature meets the project goals. Miscellany 23. FORKING Rarely is it necessary or advisable to fork an open source project. However, there are times when it is. So here are some guidelines to forking a project and distributing that forked project. a: Retain all copyright notices, and the license, and give credit where credit is due. b: As per the GPLv2 all authors of the forked project retain the copyright of the forked work. c: Give your fork a new name, and in the help indicate that it is a fork. d: Ensure that your project can be installed alongside the fork in the same environment and co-exist with it. e.g.: If you fork the Products module and call it MyProducts you may need to change preference names, database table names and other code so that the two addon modules can co-exist. Note: If you wish to distribute your forked project on the NT forge then you must also follow the forge rules document. 24: COMPLAINING / REPORTING SOMEBODY. If you feel that you absolutely must report a forum or forge user for poor behavior or breaking the above rules, please either try to use the online tools of the forum or forge (if available) or contact one of the forum moderators or Dev Team members directly via email. And please, provide evidence of the behavior. 25: RULES ARE SUBJECT TO CHANGE. STAY INFORMED. As with any project or on-line document they continually evolve as different problems are encountered. Therefore please stay tuned to new additions to this document from time to time. Consequences / Sanctions For people who break the above rules and guidelines there are a number of remedies available to the maintainers of the various NT tools and channels. These include: a: A single, private and polite warning. Usually, this is all it takes to resolve an issue. b: Removing or moving your posts Without notice or appeal, we may just delete your posts if they are found to be violating our rules or guidelines. We may also move them to a more appropriate section of the forum, which may be considered sufficient assistance. c: Restricting your forum and/or forge account. Without notice or appeal, depending on the severity of the problem encountered we may restrict your forum or forge accounts in various ways. d: Being banned Usually for repeated problems or obvious spammers, but depending on the severity of the infraction we reserve the right to ban your forum and/or forge accounts without notice or appeal. Thankfully this has not happened very often. e: The removal of your projects from the forge. If you are banned from the forum or forge, and/or have violated the forge rules we may remove projects from the forge that you are the owner/administrator of. f: Stop-forum-spam and other on-line tools. For spammers we regularly contribute to the on-line community by reporting you to Stop-forum-spam and other on-line tools. g: Reporting to authorities. For obvious illegal activities we reserve the right to contact appropriate authorities and will willingly cooperate with them. Thankfully this has not yet occurred.

Page 1 of 466  >  >>

China to strengthen its own presence: remove foreign hardware and software


Dec 10, 2019 | Category: General | Comments

Should boost local innovation instead.

read more…

OnePlus can make a surprising comeback


Dec 9, 2019 | Category: General | Comments

This may be the OnePlus 8 Lite.

read more…

Are you afraid to walk alone in the dark? Now Google will help you


Dec 8, 2019 | Category: Google | Comments

Many have wanted this feature.

read more…

Page 1 of 466  >  >>