Comments (7)
I think there are two issues:
- Contacting the submitter afterwards to ask for clarifications, in case edits are needed (e.g. to make structure consistent, to fill in some newly requested information, etc).
- Attaching authorship to use cases.
For 1, I am ok with a policy that if people don't respond to a request on github, we will delete their use case. Note however that this may "orphan" some features, e.g. if we delete a use case that is motivating some feature, and then it breaks the link from that feature back to its motivation. If the feature is in fact important then someone else would have to write a new use case, etc. creating extra work. However, really the general policy to discuss is whether we should delete use cases if we can't contact the submitters (github or otherwise). Also, people may WANT us to contact them via email rather than github.
For 2, the question is whether we want to support "anonymous" use case submissions. I'm not even sure we can do copyright transferal technically if we don't know who the submitter is. I would also feel uncomfortable personally publishing something anonymous - it does not give readers traceability to the "origin", and I don't see a strong case for making use cases anonymous.
from wot-usecases.
Also see #285 which addresses this at least partially
from wot-usecases.
I agree with the direction.
I think we need to improve the explanations for each item. On the other hand, I think we also need to consider how submitters will fill in each item.
from wot-usecases.
My opinions on this topic:
- We got many use cases in the past with the people's names. If some do not want to have their real name, let it be. We can get by with 1% less use case submissions. We have 30+ use cases to be submitted from the TD TF already.
- We should collect real names of people and those names should appear in the final document, as they do today.
- A documented way to contact the submitter should exist before a Use Case is even considered for requirement analysis. This should be stored in a private fashion (e.g. at Kaz) but should be usable by UC TF moderators to contact the submitter later on. It doesn't have to be an email but most probably it will be an email. GitHub id is not enough for contacting a person.
from wot-usecases.
I also think that submitters should need to indicate their real names. But real names maybe have privacy issues. So we need to be careful managing real names. We should follow W3C privacy policies if W3C have privacy policies.
I don't know why gitHub id is not enough for contacting a person. I think think it's the same whether it's e-mail or Github ID. I think it is important that we have several kind of contact means. If we can not contact them with Github ID, their use cases should be rejected.
from wot-usecases.
I don't know why gitHub id is not enough for contacting a person.
How would you concretely contact a person through their GitHub id? No matter what we agree on, "contacting a person through their GitHub id" should be clarified.
You can ping them on an issue but they may not watch that repo and may not be pinged. Additionally, they may not manage their GitHub account through their usual email account and may not see the notification. Also, it is not mandatory to put an email on a GitHub profile.
For me it is definitely not the same to contact via pinging a person on a GitHub issue and emailing them.
If we can not contact them with Github ID, their use cases should be rejected.
I would be fine with this. We have enough use cases waiting for this pipeline to be finalized. If we ever get to a point that we do not have enough use cases to process, we can decide to be less strict.
from wot-usecases.
Anyway, I think people can submit a use case anonymously or using only their github ID but I feel that by the time we publish a use case we should know who submitted it, we should have a way to contact them (this does not need to be made public), and we should treat it like a "publication" from the submitter, including (with, MAYBE some exceptions in rare cases) Real-Name authorship attribution.
from wot-usecases.
Related Issues (20)
- Who/how to submit UCs? HOT 1
- How to deal with gap analysis? Ned clear definition for "gap analysis HOT 1
- How to deal with gap analysis? Need clear definition for "gap analysis" HOT 5
- The structure/category of the use case description HOT 1
- What level (technical, functional, business, etc.) to be described for use cases? HOT 1
- What would be the possible items for use case description?
- How to deal with the feedback from the TFs working on each specification HOT 1
- Expectations of the TD stakeholders from the Use Case process
- What we mean by "functional" and "technical"
- What we expect for "user stories" from the Use Case description HOT 3
- Geolocation Requirement Analysis
- Mention Possibility of External Submissions via Issues
- [UC] Orchestration Between AI-enhanced Wearable Devices and Secondary Displays
- [UC Template] "What to be done?" is ambiguous HOT 2
- [UC Template] Typos HOT 2
- [UC Template] Stakeholders HOT 1
- [UC Template] Security and Privacy Categories
- [TEST] Historical Data HOT 3
- [TEST] Smart home: Leaving and Coming Home HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wot-usecases.