santosomar
commented
10 months ago Hi @sparrell,
I wholeheartedly agree with your suggestion to establish a repository, or a subdirectory within an existing repo, for the submission of use cases. This approach not only streamlines the collection of various scenarios but also encourages a broader understanding of how diverse environments and requirements can influence the application of our work.
Your point about the non-refutation of use cases is well-taken. It's important that our platform remains open to how individuals and organizations uniquely utilize the software, rather than limiting our scope to what we currently support or envision. This open-mindedness is crucial for innovation and adaptability.
The structure you propose — with a dedicated subdirectory for 'contributor use cases' and a potential 'agreed to general use cases' — is a pragmatic solution to avoid contention. It encourages contributors to freely express their unique scenarios, while also providing a path to consolidate widely applicable use cases.
I'm in favor of moving forward with this proposal and would be interested in discussing the next steps with the TC to implement this system effectively.
Now that we have the new TC formed and the TC GitHub repository. I will move this suggestion to the working items /issues there.
I think we should have either a repo, or a subdirectory of a repo, for people to submit use cases.
I will use the term use cases in the general English usage of the words (ie a case where something is used) but the software development purists might claim these are scenarios not formal use cases (note I didn't use word formal in what I proposed).
IMHO people shouldn't refute other people's use cases (just because sFractal doesn't do something doesn't mean someone else doesn't do it). Conversely, people can't submit other people's use cases (eg I at sFractal can't say 'at Redhat they do .... or as happens more often 'I think someone might ...'). Ie just speak for yourself.
If this gets contentious (it usually does as we tend to talk past each other assuming other people use our context not theirs), I found it useful to have a subdir for 'agreed to general usecases' and a subdir for 'contributor use cases'. We start with everyone submitting their own use cases into their own subdir of the contributor use cases (eg I'd put them in usecases/contrbutor/sFractal). If everyone agrees a particular sfractal use case is 'general enough', then it gets copied (maybe edited first) into usecases/general. Usually we don't need the general use cases and just develop the spec from the pile of contributor use cases. But having documented use cases does allow all of us to see the different perspectives.
This tends to be most useful in contrasting situations. One is the commercial closed source vendor vs the MIT license open source github library (and I realize there are many other variants than these two). Another is between hard-to-update-IoT devices vs classic server app vs cloud whatever-as-a-service. Delineating the use cases helps us recognize when person A was talking one situation applicable to their environment and person B was talking about a different situation applicable to their environment.
The other advantage of the 'everybody in their own subdir for use cases' and 'don't bother about the general use casses' is you don't spend months arguing about them.