Merge pull request #54 from DigiByte-Core/bugfix/updated-contribution-md

Docs: Replaced IRC references with Gitter references

CONTRIBUTING.md

@@ -9,7 +9,7 @@ If you're looking for somewhere to start contributing, check out the [good first
 ## Communication Channels
 
 Most communication about DigiByte Core development happens in the
-[DigiByte Official Developers](https://t.me/DigiByteDevelopers) channel on Telegram. The easiest way to participate on Telegram one of the freely available clients, [www.telegram.org](https://telegram.org/).
+[Protocol](https://gitter.im/DigiByte-Core/protocol) channel on Gitter. The easiest way to participate on Gitter is via one of the freely available clients, [Gitter Apps](https://gitter.im/apps).
 
 Discussion about code base improvements happens in GitHub issues and on pull requests.
 
@@ -134,7 +134,7 @@ Patches that change DigiByte consensus rules are considerably more involved than
 
 ### Peer Review
 
-Anyone may participate in peer review which is expressed by comments in the pull request. Typically reviewers will review the code for obvious errors, as well as test out the patch set and opine on the technical merits of the patch. Project maintainers take into account the peer review when determining if there is consensus to merge a pull request (remember that discussions may have been spread out over GitHub, mailing list and IRC discussions). The following language is used within pull-request comments:
+Anyone may participate in peer review which is expressed by comments in the pull request. Typically reviewers will review the code for obvious errors, as well as test out the patch set and opine on the technical merits of the patch. Project maintainers take into account the peer review when determining if there is consensus to merge a pull request (remember that discussions may have been spread out over GitHub, Gitter, Telegram, and mailing lists). The following language is used within pull-request comments:
 
 - ACK means "I have tested the code and I agree it should be merged";
 - NACK means "I disagree this should be merged", and must be accompanied by sound technical justification (or in certain cases of copyright/patent/licensing issues, legal justification). NACKs without accompanying reasoning may be disregarded;
@@ -148,16 +148,16 @@ Project maintainers reserve the right to weigh the opinions of peer reviewers us
 
 Where a patch set affects consensus critical code, the bar will be set much higher in terms of discussion and peer review requirements, keeping in mind that mistakes could be very costly to the wider community. This includes refactoring of consensus critical code.
 
-Where a patch set proposes to change the DigiByte consensus, it must have been discussed extensively on the mailing list and IRC, be accompanied by a widely discussed BIP and have a generally widely perceived technical consensus of being a worthwhile change based on the judgement of the maintainers.
+Where a patch set proposes to change the DigiByte consensus, it must have been discussed extensively on GitHub & Gitter, be accompanied by a widely discussed DIP and have a generally widely perceived technical consensus of being a worthwhile change based on the judgement of the maintainers.
 
 ### Finding Reviewers
 
 As most reviewers are themselves developers with their own projects, the review process can be quite lengthy, and some amount of patience is required. If you find that you've been waiting for a pull request to be given attention for several months, there may be a number of reasons for this, some of which you can do something about:
 
 - It may be because of a feature freeze due to an upcoming release. During this time, only bug fixes are taken into consideration. If your pull request is a new feature, it will not be prioritized until the release is over. Wait for release.
-- It may be because the changes you are suggesting do not appeal to people. Rather than nits and critique, which require effort and means they care enough to spend time on your contribution, thundering silence is a good sign of widespread (mild) dislike of a given change (because people don't assume *others* won't actually like the proposal). Don't take that personally, though! Instead, take another critical look at what you are suggesting and see if it: changes too much, is too broad, doesn't adhere to the [developer notes](doc/developer-notes.md), is dangerous or insecure, is messily written, etc. Identify and address any of the issues you find. Then ask e.g. on IRC if someone could give their opinion on the concept itself.
+- It may be because the changes you are suggesting do not appeal to people. Rather than nits and critique, which require effort and means they care enough to spend time on your contribution, thundering silence is a good sign of widespread (mild) dislike of a given change (because people don't assume *others* won't actually like the proposal). Don't take that personally, though! Instead, take another critical look at what you are suggesting and see if it: changes too much, is too broad, doesn't adhere to the [developer notes](doc/developer-notes.md), is dangerous or insecure, is messily written, etc. Identify and address any of the issues you find. Then ask e.g. on Gitter if someone could give their opinion on the concept itself.
 - It may be because your code is too complex for all but a few people. And those people may not have realized your pull request even exists. A great way to find people who are qualified and care about the code you are touching is the [Git Blame feature](https://help.github.com/articles/tracing-changes-in-a-file/). Simply find the person touching the code you are touching before you and see if you can find them and give them a nudge. Don't be incessant about the nudging though.
-- Finally, if all else fails, ask on IRC or elsewhere for someone to give your pull request a look. If you think you've been waiting an unreasonably long amount of time (month+) for no particular reason (few lines changed, etc), this is totally fine. Try to return the favor when someone else is asking for feedback on their code, and universe balances out.
+- Finally, if all else fails, ask on Gitter or elsewhere for someone to give your pull request a look. If you think you've been waiting an unreasonably long amount of time (month+) for no particular reason (few lines changed, etc), this is totally fine. Try to return the favor when someone else is asking for feedback on their code, and universe balances out.
 
 ## Release Policy
 

doc/README.md

@@ -34,8 +34,7 @@ Drag DigiByte Core to your applications folder, and then run DigiByte Core.
 
 * See the documentation at the [DigiByte Wiki](https://en.digibyte.it/wiki/Main_Page)
 for help and more information.
-* Ask for help on [#digibyte](http://webchat.freenode.net?channels=digibyte) on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net?channels=digibyte).
-* Ask for help on the [DigiByteTalk](https://digibytetalk.org/) forums, in the [Technical Support board](https://digibytetalk.org/index.php?board=4.0).
+* Ask for help on [Gitter](https://gitter.im/DigiByte-Core/protocol). If you don't have a Gitter client [find one here](https://gitter.im/apps).
 
 Building
 ---------------------
@@ -67,11 +66,12 @@ The DigiByte repo's [root README](/README.md) contains relevant information on t
 - [Benchmarking](benchmarking.md)
 
 ### Resources
-* Discuss on the [DigiByteTalk](https://digibytetalk.org/) forums, in the [Development & Technical Discussion board](https://digibytetalk.org/index.php?board=6.0).
-* Discuss project-specific development on #digibyte-core-dev on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net/?channels=digibyte-core-dev).
-* Discuss general DigiByte development on #digibyte-dev on Freenode. If you don't have an IRC client use [webchat here](http://webchat.freenode.net/?channels=digibyte-dev).
+
+- Discuss project-specific development on [Gitter](https://gitter.im/DigiByte-Core/protocol). If you don't have a Gitter client find one [here](https://gitter.im/apps).
+- Discuss general DigiByte development on the general Gitter channel [here](https://gitter.im/DigiByte-Core/community).
 
 ### Miscellaneous
+
 - [Assets Attribution](assets-attribution.md)
 - [Files](files.md)
 - [Fuzz-testing](fuzzing.md)

doc/release-process.md

@@ -3,7 +3,7 @@ Release Process
 
 Before every release candidate:
 
-* Update translations (ping wumpus on IRC) see [translation_process.md](https://github.com/digibyte/digibyte/blob/master/doc/translation_process.md#synchronising-translations).
+* Update translations see [translation_process.md](https://github.com/digibyte/digibyte/blob/master/doc/translation_process.md#synchronising-translations).
 
 * Update manpages, see [gen-manpages.sh](https://github.com/digibyte/digibyte/blob/master/contrib/devtools/README.md#gen-manpagessh).
 
@@ -45,9 +45,6 @@ Write release notes. git shortlog helps a lot, for example:
 
     git shortlog --no-merges v(current version, e.g. 0.7.2)..v(new version, e.g. 0.8.0)
 
-(or ping @wumpus on IRC, he has specific tooling to generate the list of merged pulls
-and sort them into categories based on labels)
-
 Generate list of authors:
 
     git log --format='- %aN' v(current version, e.g. 0.16.0)..v(new version, e.g. 0.16.1) | sort -fiu
@@ -296,8 +293,6 @@ digibyte.org (see below for digibyte.org update instructions).
 
   - digibytecore.org blog post
 
-  - Update title of #digibyte on Freenode IRC
-
   - Optionally twitter, reddit /r/DigiByte, ... but this will usually sort out itself
 
   - Notify BlueMatt so that he can start building [the PPAs](https://launchpad.net/~digibyte/+archive/ubuntu/digibyte)

doc/translation_process.md

@@ -100,6 +100,6 @@ To create a new language template, you will need to edit the languages manifest
 **Note:** that the language translation file **must end in `.qm`** (the compiled extension), and not `.ts`.
 
 ### Questions and general assistance
-The DigiByte-Core translation maintainers include *tcatm, seone, Diapolo, wumpus and luke-jr*. You can find them, and others, in the Freenode IRC chatroom - `irc.freenode.net #digibyte-core-dev`.
+The DigiByte-Core translation maintainers can be found on [Gitter](https://gitter.im/DigiByte-Core/protocol).
 
-If you are a translator, you should also subscribe to the mailing list, https://groups.google.com/forum/#!forum/digibyte-translators. Announcements will be posted during application pre-releases to notify translators to check for updates.
+If you are a translator, you should connect with contributors on [Gitter](https://gitter.im/DigiByte-Core/protocol). Announcements will be posted during application pre-releases to notify translators to check for updates.