From 1b23e10328a373866574accfaed7180e434c2664 Mon Sep 17 00:00:00 2001 From: JustArchi Date: Thu, 22 Nov 2018 05:44:08 +0100 Subject: [PATCH] Update CONTRIBUTING.md --- .github/CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 65121ecc2..c5e32263e 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -34,11 +34,11 @@ It would also be cool if you could reproduce your issue on latest **[pre-release While everybody is able to create suggestions how to improve ASF, GitHub issues is not the proper place to discuss if your enhancement makes sense - by posting it you already **believe** that it makes sense, and you're **ready to convince us how**. If you have some idea but you're not sure if it's possible, makes sense, or fits ASF purpose - you have **[Steam group](https://steamcommunity.com/groups/archiasf/discussions/1)** discussions where we'll be happy to discuss given enhancement in calm atmosphere, evaluating possibilities and pros/cons. This is what we suggest to do in the first place, as in GitHub issue you're switching from **having an idea** into **having a valid enhancement with general concept, given purpose and fixed details - you're ready to defend your idea and convince us how it can be useful for ASF**. This is the general reason why many issues are rejected - because you're lacking details that would prove your suggestion being worthy. -ASF has a strict scope - idling Steam cards from Steam games + basic bots management. ASF scope is very subjective and evaluated on practical/moral basis - how much this feature fits ASF, how much actual coding effort is required to make it happen, how useful/wanted this feature is by the community and likewise. In general we don't mind further enhancements to the program, as there is always a room for improvement, but at the same time we consider ASF to be feature-complete and vast majority of things that ASF is simply out of the scope of ASF as a program. This is why we've rejected **[a lot](https://github.com/JustArchiNET/ArchiSteamFarm/issues?q=label%3AEnhancement+label%3A%22Not+going+to+happen%22)** of similar enhancements, for various different reasons, mainly regarding the scope of the program. Some people might find it hard to understand why we're rather sceptical towards suggestions, while the answer for that isn't obvious at first. +ASF has a strict scope - idling Steam cards from Steam games + basic bots management. ASF scope is very subjective and evaluated on practical/moral basis - how much this feature fits ASF, how much actual coding effort is required to make it happen, how useful/wanted this feature is by the community and likewise. In general we don't mind further enhancements to the program, as there is always a room for improvement, but at the same time we consider ASF to be feature-complete and vast majority of things that are suggested today are simply out of the scope of ASF as a program. This is why we've rejected **[a lot](https://github.com/JustArchiNET/ArchiSteamFarm/issues?q=label%3AEnhancement+label%3A%22Not+going+to+happen%22)** of general enhancements, for various different reasons, mainly regarding the scope of the program. Some people might find it hard to understand why we're rather sceptical towards suggestions, while the answer for that isn't obvious at first. > In the lifetime of an Open Source project, only 10 percent of the time spent adding a feature will be spent coding it. The other 90 percent will be spent in support of that feature. -This includes especially maintenance of that feature, such as documenting it, keeping that documentation up-to-date, ensuring this feature won't break between one version and another, actively supporting that feature (including answering people how it works, why it doesn't work the way they want, and why it works like that), on top of all usual code maintenance, refactoring and writing it in the first place. We code ASF in our free time, and our free time is not infinite. Moreover, even if it was infinite then we'd still not be able to please everybody, as it's simply not possible to create a program that satisfies everyone. Developing any kind of software project is always about compromise - you can't possibly have everything. Using ASF for checking weather or reminding you to feed your cat isn't necessarily within the program's scope. Posting comments on profiles, sorting your games library or managing your Steam inventory isn't within that scope either. You don't have to agree with us, but you have to respect our decision as project maintainers when you make a suggestion that simply isn't what ASF was designed to do. +This includes especially maintenance of that feature, such as documenting it, keeping that documentation up-to-date, ensuring this feature won't break between one version and another, actively supporting that feature (including answering people how it works, why it doesn't work the way they want, and why it works like that), on top of all usual code maintenance, refactoring and writing it in the first place. We code ASF in our free time, and our free time is not infinite. Moreover, even if it was infinite then we'd still not be able to please everybody, as it's simply not possible to create a program that satisfies everyone. Developing any kind of software project is always about compromise - you can't possibly have everything. Using ASF for checking weather or reminding you to feed your cat isn't necessarily within the program's scope. Posting comments on profiles, sorting your games library or managing your Steam inventory isn't within that scope either. You don't have to agree with us, but you have to respect our decision as project maintainers when you make a suggestion that simply isn't what ASF was designed to do. ASF is open-source project, if you can't live without some feature then you can always code it **yourself**, and if that's too much for you, then like it or not, but you have to respect our decision whether **we** will decide to code it. After ASF scope, we come to Steam ToS. There is no place for discussion here - if we think that something goes too much from the gray zone and is directly or indirectly against Steam ToS, we'll **always** reject it. Some good examples in this category include any automation related to the Steam store or Steam market. Both services are directly claimed to be subscription marketplaces, and automating any subscription marketplace is against Steam ToS. We're not in position to state if we agree with Steam ToS or not - we're doing our best to follow it. Interpretation of Steam ToS and what in fact is allowed or not, is also very subjective, as ToS itself is very vague and unclear in almost every possible aspect. However, the fact remains the same - we do not code, neither accept features that are in direct or indirect conflict with Steam ToS when there is no strong reasoning that we're wrong about making that call. You should check Steam **[ToS](https://store.steampowered.com/subscriber_agreement/english)** and **[online conduct](https://store.steampowered.com/online_conduct?l=english)** at the minimum.