CMSMS CODE OF CONDUCT

The CMSMS documentation sites, forum and forge, and IRC (now Slack) 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 CMSMS 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.

Definitions

• a: The CMSMS Core

  The CMSMS Core is the software package built and distributed by the CMSMS Dev Team as 'CMS Made Simple'. It consists of several modules, plugins files, libraries, scripts, images, etc. and is what would be installed without installing third party plugins or add-ons, templates, style sheets, or images.

• b: Third party add-ons

  Third party add-ons are utilities, scripts, themes, modules, programs or plugins that are not officially distributed by the CMSMS Dev Team.

Note: Often third-party add-ons will be written by the same people who contribute to the CMSMS core. This is natural, and these third party contributions are completely separate and not to be considered part of the core. You can envision that these developers, when working on the core, take off their "third party developer hat", and put on their "core developer hat". There are fewer concerns a developer has when writing a third party add-on than when writing core functionality. Conversely, because somebody is a core developer, it does not mean that they have access to or are familiar with all third party modules.

Channels

Note: All the rules and guidelines below apply equally whether posting publicly on the CMSMS Forum, the Forge, Slack, documentation sites, or via the Private Message mechanism, or any communication mechanism provided by the CMSMS 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 CMSMS specifically

The CMSMS 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 CMSMS-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 CMSMS core
  • - The CMSMS Documentation website, including the troubleshooting page and knowledge base section.
  • - The default content pages, templates, and style-sheets distributed with CMSMS
  • - The help for installed tags available by clicking the 'help' link on each row in the Extensions >> Tags page of the CMSMS admin console.
  • - The help for installed modules available by clicking the 'help' link on each row in the Extensions >> Modules page of the CMSMS admin console.
  • - The Smarty documentation
  • - The changelog that is updated for each released CMSMS 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 CMSMS admin console.
  • - The help for installed modules available by clicking the 'help' link on each row in the Extensions >> Modules page of the CMSMS 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 CMSMS admin console.

• C: Google, and search the forums

  Googling and searching the CMSMS forum (you can even search the CMSMS 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. Upgrade before you post.

• a: The Dev Team only supports the two most recent versions of CMSMS.

  i.e: if the latest version is 2.1.6 we will support issues is 2.1.5 and 2.1.6, but no previous versions. Posting questions about older versions is just wasting time.

• b: Module developers often try to fix known (and reproducible) issues when releasing new versions of their modules.

  If you are not running the latest version of the software and are experiencing a difficulty then you are again wasting time.

5. 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.

6. 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.

7. 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 CMSMS 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, CMSMS's debug mode, CMSMS's Audit log, and the browser's javascript/network console.

  See the 'Knowledge base' and the 'Troubleshooting' pages of the CMSMS 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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://www.cmsmadesimple.org/partners/advertising/]

13. 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.

14. 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.

15. 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

17: 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 CMSMS 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.

18: 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.

19. 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

20: 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.

21: 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

22: 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.

23: 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.

24: 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.

25: 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 CMSMS 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

26. 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 CMSMS forge then you must also follow the forge rules document.

27: 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.

28: 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 CMSMS 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.

References

• i: The GPL (v2)
• ii: The CMSMS Forum
• iii: The CMSMS Forge
• iv: The CMSMS Docs site
• v: The CMSMS API Docs site
• vi: The CMSMS Forge rules document