From: Diogo Cordeiro Date: Tue, 11 Jun 2019 23:39:50 +0000 (+0100) Subject: [DOCUMENTATION] Minor corrections X-Git-Url: https://git.mxchange.org/?a=commitdiff_plain;h=2740ff8c4c786381f45a48cf0437bc3f9005067e;p=quix0rs-gnu-social.git [DOCUMENTATION] Minor corrections Add two missing contributors Bumped patch due to changed introduced with 0583a6a904 --- diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000000..038e00418a --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,95 @@ +## Code of Conduct + +### Our Pledge + +In the interest of fostering an open and welcoming environment, we as +contributors and maintainers pledge to making participation in our project and +our community a harassment-free experience for everyone, regardless of age, body +size, disability, ethnicity, gender identity and expression, level of experience, +nationality, personal appearance, race, religion, or sexual identity and +orientation. + +### Our Standards + +Examples of behavior that contributes to creating a positive environment +include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or +advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic + address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a + professional setting + +### Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable +behavior and are expected to take appropriate and fair corrective action in +response to any instances of unacceptable behavior. + +Project maintainers have the right and responsibility to remove, edit, or +reject comments, commits, code, wiki edits, issues, and other contributions +that are not aligned to this Code of Conduct, or to ban temporarily or +permanently any contributor for other behaviors that they deem inappropriate, +threatening, offensive, or harmful. + +### Scope + +This Code of Conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. Examples of +representing a project or community include using an official project e-mail +address, posting via an official social media account, or acting as an appointed +representative at an online or offline event. Representation of a project may be +further defined and clarified by project maintainers. + +### Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by contacting the project team at mattl@gnu.org. All +complaints will be reviewed and investigated and will result in a response that +is deemed necessary and appropriate to the circumstances. The project team is +obligated to maintain confidentiality with regard to the reporter of an incident. +Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good +faith may face temporary or permanent repercussions as determined by other +members of the project's leadership. + +### Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, +available at [http://contributor-covenant.org/version/1/4][version] + +[homepage]: http://contributor-covenant.org +[version]: http://contributor-covenant.org/version/1/4/ + + +## The Code of Conflict + +GNU social has a high submission standard and we want to keep quality code in the +codebase and bad code out of it. As such your code will be closely scrutinized, +and you might take this criticism personally. Please understand that this is +meant to keep the standards of the codebase up, and isn't meant personally. All +the same, this isn't an excuse for poor behaviour, and a reviewer shouldn't be +misbehaving towards submitters. + + +If however, anyone feels personally abused, threatened, or otherwise +uncomfortable due to this process, that is not acceptable. If so, please +contact the project team at mattl@gnu.org, and they will work to resolve the issue +to the best of their ability. + +As a reviewer of code, please strive to keep things civil and focused on the +technical issues involved. We are all humans, and frustrations can be high on +both sides of the process. Try to keep in mind the immortal words of Bill and +Ted, "Be excellent to each other." diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000000..5911177970 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,112 @@ +# Contributing to GNU social + +First of all, if you're reading this intending to contribute to GNU social, +thanks! Free software development only happens when people like you take an +interest in giving back to the software they themselves use, and their +community. + +When contributing to this repository, please first discuss the change you wish to +make via issue, email, or any other method with the owners of this repository before +making a change. + +There's a few files you should read before going forward with a merge request +or a patch submission. They detail what this file touches on in brief. They +are: + +* `DOCUMENTATION/DEVELOPERS/CONTRIBUTING/coding_standards.md`: How your code should be structured and formatted to be + accepted into the GNU social codebase. +* `/DOCUMENTATION/DEVELOPERS/CONTRIBUTING/merge_request_checklist.md`: A quick checklist to review before submission. + + +## Merge Request Process + +1. Ensure you strip any trailing spaces off and checked the file with php-cs-fixer +2. Increase the version numbers in any examples files and the README.md to the new version that this + Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/). +3. You may merge the Pull Request in once you have the sign-off of two other developers, or if you + do not have permission to do that, you may request the second reviewer to merge it for you. + + +## Coding Standards + +Since we will be expected to maintain your code once it's submitted, we ask you +to adhere to certain coding standards that make it easier for us to do so. If +code doesn't follow them, it will be rejected, so please read up on these. + + +## Bug Reports + +Please report bugs to the issue tracker at + Avoid assigning the labels +yourself, as these are for the development team to assign priority and area of +coverage to a subject. Please only submit something here if you are certain it +is a bug or represents a feature enhancement that we do not presently have. If +you are uncertain whether it's a bug, please feel free to ask +at #social IRC channel on freenode.net https://www.freenode.net/. + +When reporting a bug, please try to include as much information as possible, +including the environment being run on (if it's a common LAMP stack just give +us version numbers of the main stack components, that's fine), and the specific +error you get. If you do not get a client-facing error, please check the PHP +error_log and ensure there isn't something silently reported there, as well as +the GNU social log. Try to include steps to reproduce the error as well, as if +we cannot reproduce the error, we can't fix it! + +It is perfectly acceptable to reference the archive page of a discussion on the +mailing list for the bug report, by the way, as long as it includes all the +information we need for a bug report. + + +## Submitting Feature Requests / Enhancement Requests + +Social media is constantly evolving, and we welcome ideas about how we can +change and evolve GNU social to keep it the excellent piece of software that it +is. However, there are a few things we ask you do when submitting feature +requests: + +1. Understand that since we have a limited amount of developers and these people +contribute in their free time, we may prioritize things differently than you +value them. Oftentimes this is because certain requests involve less changes +to the existing codebase than others, and therefore this makes them easier +to add. +2. Please search the existing feature requests and enhancements to see if a +similar request exists. If one does but you have different ideas about how +to do it or what it should entail, please add a comment to the existing idea +rather than create a new one for your "version" of it. Duplicate submissions +mean we spend more time maintaining the tracker and less time actually +working on the codebase! +3. When outlining the way that you see something working, don't be afraid to be +as detailed as possible! We may not implement it exactly as you describe for +any variety of reasons, but the more concrete and fleshed out an idea is, the +easier it is for us to know what you want and be able to implement it in a +sane and secure fashion. +4. When describing a possible new idea and its mechanisms of operation, the key +words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the issue submission +are to be interpreted as described in RFC 2119. + + +Finally, and just as a call back to the first point, realize just because we +might not rush to implement something, doesn't mean that we don't want to +implement it! We would rather take the time to do something right the first +time, then hurriedly apply a new idea, or a fix, only to have to patch it later. + + +## Branch of Code Submissions + +Unless you've been specifically directed otherwise, all submissions of code +should be against the `nightly` branch, so make sure any modifications are based +on Nightly. + + +## Copyright / Licensing + +You acknowledge that by submitting code to GNU social, you are licensing it under +the GNU AGPLv3 unless there is an extenuating circumstance where it would be +licensed differently (such as modifications to an external library we include +such as Stomp). + +You also acknowledge that unless you assign a copyright explicitly, it will be +assumed to be assigned to GNU social. + +Thanks for considering submission, and happy hacking! diff --git a/CREDITS.md b/CREDITS.md index 172e16d930..79651fbbf4 100644 --- a/CREDITS.md +++ b/CREDITS.md @@ -13,6 +13,7 @@ Current team * Diogo Cordeiro * Bruno Casteleiro * Miguel Dantas +* Alexei Sorokin Additional Contributors ----------------------- @@ -54,6 +55,8 @@ Additional Contributors * Moonman * Normandy * Verius +* Alexei Sorokin +* Daniel Supernault Credits for StatusNet -------------- diff --git a/DOCUMENTATION/DEVELOPERS/CONTRIBUTING/README.md b/DOCUMENTATION/DEVELOPERS/CONTRIBUTING/README.md deleted file mode 100644 index 1c7d0d9c15..0000000000 --- a/DOCUMENTATION/DEVELOPERS/CONTRIBUTING/README.md +++ /dev/null @@ -1,198 +0,0 @@ -# Contributing to GNU social - -First of all, if you're reading this intending to contribute to GNU social, -thanks! Free software development only happens when people like you take an -interest in giving back to the software they themselves use, and their -community. - -When contributing to this repository, please first discuss the change you wish to -make via issue, email, or any other method with the owners of this repository before -making a change. - -There's a few files you should read before going forward with a merge request -or a patch submission. They detail what this file touches on in brief. They -are: - -* coding_standards.md: How your code should be structured and formatted to be - accepted into the GNU social codebase. -* merge_request_checklist.md: A quick checklist to review before submission. - -## Merge Request Process - -1. Ensure you strip any trailing spaces off and checked the file with php-cs-fixer -2. Increase the version numbers in any examples files and the README.md to the new version that this - Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/). -3. You may merge the Pull Request in once you have the sign-off of two other developers, or if you - do not have permission to do that, you may request the second reviewer to merge it for you. - - -## Code of Conduct - -### Our Pledge - -In the interest of fostering an open and welcoming environment, we as -contributors and maintainers pledge to making participation in our project and -our community a harassment-free experience for everyone, regardless of age, body -size, disability, ethnicity, gender identity and expression, level of experience, -nationality, personal appearance, race, religion, or sexual identity and -orientation. - -### Our Standards - -Examples of behavior that contributes to creating a positive environment -include: - -* Using welcoming and inclusive language -* Being respectful of differing viewpoints and experiences -* Gracefully accepting constructive criticism -* Focusing on what is best for the community -* Showing empathy towards other community members - -Examples of unacceptable behavior by participants include: - -* The use of sexualized language or imagery and unwelcome sexual attention or -advances -* Trolling, insulting/derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or electronic - address, without explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional setting - -### Our Responsibilities - -Project maintainers are responsible for clarifying the standards of acceptable -behavior and are expected to take appropriate and fair corrective action in -response to any instances of unacceptable behavior. - -Project maintainers have the right and responsibility to remove, edit, or -reject comments, commits, code, wiki edits, issues, and other contributions -that are not aligned to this Code of Conduct, or to ban temporarily or -permanently any contributor for other behaviors that they deem inappropriate, -threatening, offensive, or harmful. - -### Scope - -This Code of Conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. Examples of -representing a project or community include using an official project e-mail -address, posting via an official social media account, or acting as an appointed -representative at an online or offline event. Representation of a project may be -further defined and clarified by project maintainers. - -### Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the project team at [INSERT EMAIL ADDRESS]. All -complaints will be reviewed and investigated and will result in a response that -is deemed necessary and appropriate to the circumstances. The project team is -obligated to maintain confidentiality with regard to the reporter of an incident. -Further details of specific enforcement policies may be posted separately. - -Project maintainers who do not follow or enforce the Code of Conduct in good -faith may face temporary or permanent repercussions as determined by other -members of the project's leadership. - -### Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, -available at [http://contributor-covenant.org/version/1/4][version] - -[homepage]: http://contributor-covenant.org -[version]: http://contributor-covenant.org/version/1/4/ - - -## The Code of Conflict - -GNU social has a high submission standard and we want to keep quality code in the -codebase and bad code out of it. As such your code will be closely scrutinized, -and you might take this criticism personally. Please understand that this is -meant to keep the standards of the codebase up, and isn't meant personally. All -the same, this isn't an excuse for poor behaviour, and a reviewer shouldn't be -misbehaving towards submitters. The Code of Conflict outlines the dispute -resolution mechanism if something does come up, so give it a read. - - -## Coding Standards - -Since we will be expected to maintain your code once it's submitted, we ask you -to adhere to certain coding standards that make it easier for us to do so. If -code doesn't follow them, it will be rejected, so please read up on these. - - -## Bug Reports - -Please report bugs to the issue tracker at - Avoid assigning the labels -yourself, as these are for the development team to assign priority and area of -coverage to a subject. Please only submit something here if you are certain it -is a bug or represents a feature enhancement that we do not presently have. If -you are uncertain whether it's a bug, please feel free to ask -at #social IRC channel on freenode.net https://www.freenode.net/. - -When reporting a bug, please try to include as much information as possible, -including the environment being run on (if it's a common LAMP stack just give -us version numbers of the main stack components, that's fine), and the specific -error you get. If you do not get a client-facing error, please check the PHP -error_log and ensure there isn't something silently reported there, as well as -the GNU social log. Try to include steps to reproduce the error as well, as if -we cannot reproduce the error, we can't fix it! - -It is perfectly acceptable to reference the archive page of a discussion on the -mailing list for the bug report, by the way, as long as it includes all the -information we need for a bug report. - - -## Submitting Feature Requests / Enhancement Requests - -Social media is constantly evolving, and we welcome ideas about how we can -change and evolve GNU social to keep it the excellent piece of software that it -is. However, there are a few things we ask you do when submitting feature -requests: - -1. Understand that since we have a limited amount of developers and these people -contribute in their free time, we may prioritize things differently than you -value them. Oftentimes this is because certain requests involve less changes -to the existing codebase than others, and therefore this makes them easier -to add. -2. Please search the existing feature requests and enhancements to see if a -similar request exists. If one does but you have different ideas about how -to do it or what it should entail, please add a comment to the existing idea -rather than create a new one for your "version" of it. Duplicate submissions -mean we spend more time maintaining the tracker and less time actually -working on the codebase! -3. When outlining the way that you see something working, don't be afraid to be -as detailed as possible! We may not implement it exactly as you describe for -any variety of reasons, but the more concrete and fleshed out an idea is, the -easier it is for us to know what you want and be able to implement it in a -sane and secure fashion. -4. When describing a possible new idea and its mechanisms of operation, the key -words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", -"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the issue submission -are to be interpreted as described in RFC 2119. - - -Finally, and just as a call back to the first point, realize just because we -might not rush to implement something, doesn't mean that we don't want to -implement it! We would rather take the time to do something right the first -time, then hurriedly apply a new idea, or a fix, only to have to patch it later. - - -## Branch of Code Submissions - -Unless you've been specifically directed otherwise, all submissions of code -should be against the `nightly` branch, so make sure any modifications are based -on Nightly. - - -## Copyright / Licensing - -You acknowledge that by submitting code to GNU social, you are licensing it under -the GNU AGPLv3 unless there is an extenuating circumstance where it would be -licensed differently (such as modifications to an external library we include -such as Stomp). - -You also acknowledge that unless you assign a copyright explicitly, it will be -assumed to be assigned to GNU social. - -Thanks for considering submission, and happy hacking! diff --git a/README.md b/README.md index b04a465e04..b6d1dd89d1 100644 --- a/README.md +++ b/README.md @@ -9,14 +9,14 @@ project. The file INSTALL.md has useful instructions on how to install this software. -System administrators may find the DOCUMENTATION/SYSTEM_ADMINISTRATORS +System administrators may find the `DOCUMENTATION/SYSTEM_ADMINISTRATORS` directory useful, namely: - upgrade_from: upgrading from different software - CONFIGURE.md: configuration options in gruesome detail. - PLUGINS.md: how to install and configure plugins. -Developers may find the DOCUMENTATION/DEVELOPERS directory useful. +Developers may find the `DOCUMENTATION/DEVELOPERS` directory useful. ## About @@ -121,12 +121,13 @@ In the current phase of development it is probably recommended to use git as a means to stay up to date with the source code. You can choose between these branches: -- master "stable", usually working well -- nightly "unstable", most updates, not always working as expected +* 1.20.x "oldstable", few updates, well tested coded +* master "stable", usually working well +* nightly "testing", most updates, not always working as expected To keep it up-to-date, use `git pull`. Watch for conflicts! -As in any upgrade, do `not` forget to run `/scripts/upgrade.php`. +As in any upgrade, do __not__ forget to run `/scripts/upgrade.php`. ## Further information @@ -139,3 +140,18 @@ There are several ways to get more information about GNU social. * GNU social has a bug tracker for any defects you may find, or ideas for making things better. * Patches are welcome, preferrably to our repository on notabug.org. + +## Credits + +An incomplete list of developers who've worked on GNU social, +or its predecessors StatusNet and Free Social has been made available +in `CREDITS.md`. + +### Current team + +* Matt Lee +* Mikael Nordfeldth +* Diogo Cordeiro +* Bruno Casteleiro +* Miguel Dantas +* Alexei Sorokin diff --git a/lib/framework.php b/lib/framework.php index d9149c1945..43aa0ade08 100644 --- a/lib/framework.php +++ b/lib/framework.php @@ -32,7 +32,7 @@ defined('GNUSOCIAL') || die(); define('GNUSOCIAL_ENGINE', 'GNU social'); define('GNUSOCIAL_ENGINE_URL', 'https://www.gnu.org/software/social/'); -define('GNUSOCIAL_BASE_VERSION', '1.20.0'); +define('GNUSOCIAL_BASE_VERSION', '1.20.1'); define('GNUSOCIAL_LIFECYCLE', 'release'); // 'dev', 'alpha[0-9]+', 'beta[0-9]+', 'rc[0-9]+', 'release' define('GNUSOCIAL_VERSION', GNUSOCIAL_BASE_VERSION . '-' . GNUSOCIAL_LIFECYCLE);