From ed2bf29fefc102a130b211f4a169c9d4ebb65315 Mon Sep 17 00:00:00 2001 From: Bouwe Andela Date: Mon, 6 Nov 2023 14:36:25 +0100 Subject: [PATCH] Remove communication chapter --- _sidebar.md | 1 - best_practices/communication.md | 47 --------------------------------- 2 files changed, 48 deletions(-) delete mode 100644 best_practices/communication.md diff --git a/_sidebar.md b/_sidebar.md index 66eec35..15f3272 100644 --- a/_sidebar.md +++ b/_sidebar.md @@ -4,7 +4,6 @@ * [Version Control](/best_practices/version_control.md) * [Code Quality](/best_practices/code_quality.md) * [Code Review](/best_practices/code_review.md) - * [Communication](/best_practices/communication.md) * [Testing](/best_practices/testing.md) * [Releases](/best_practices/releases.md) * [Documentation](/best_practices/documentation.md) diff --git a/best_practices/communication.md b/best_practices/communication.md deleted file mode 100644 index d6b1b94..0000000 --- a/best_practices/communication.md +++ /dev/null @@ -1,47 +0,0 @@ -# Communication - -Communication to the outside world is important for visibility of Netherlands eScience Center projects and for building -the user base. - -Communication to other developers is a way to build community and contributors. It also increases -our visibility in development world. - -## Home page - -The software should have a homepage with all the necessary introduction information, links to documentation, source code (github) and latest release download (e.g. [github.io pages](https://pages.github.com/)) - -The page should be created at the latest when the software is ready to be seen by the outside world. It is the place where people will learn about software, so it is important to describe its goals and functionality. -It should be targeted towards non-programming users (unless software is meant for programers i.e library) but should have -pointers for developers to more advanced resources (README.md) - -## Discussion list - -Github issues, mailing list, not private email, for all project related -discussions from the beginning of the project - -There should be no private discussions about the project. Therefore once discussions are started -(in the email), either move them to github issues or if they don’t fit into issues format any more, -create the mailing list. - -## Demo docker image in dockerhub (with Dockerfile) - -When applies, usually for services. - -If software is the service, Docker image should be created at a very early stage. This will allow for easier testing and platform -independent use. - -## An online demo - -Only for web applications - -Online demo should be available since first stable release. -When the website is the user interface for researchers, make sure there is a development version -running somewhere so that they can *play around with it* and give usability feedback. - -## Screencast - -For most software it should be possible to create a screencast. This is very useful for people to get a quick impression of what exactly you are doing without diving into the code itself. In case your software does not have a graphical user interface, even a screencast of a terminal session can be quite informative. Try to add audio, or at least subtitles, so people know what is going on in the video. - -At the Netherlands eScience Center we gather screencasts in our [Youtube Channel](https://www.youtube.com/user/NLeScienceCenter). - -