How can we better propose "new quest types"?

[rugk]

Starting a discussion about the reoccurring problems of how quests can be proposed.

The problem

• Getting new quest suggestion is time-consuming
• We cannot stop people from proposing quests, also because this is a very legitimate thing for a FLOSS project, where the main thing are these quests
• Often people do not think about all aspects/requirements involved when creating quests
• Often it is hard to decide and needs some discussion (see "needs time")
• This problem won't go away with more and more app users.
• It would be best if more people would develop these quests and sent PRs as development time is needed, not ideas for quests.

What we have…

• Only the wiki, which I think is more about developing/implementing a quest. It has, however, also some requirements listed.
• And some general information about the aim of the project in the Readme. (That's good, but specific requirements are still unclear to issue creators)

Generally both things require the issue creator to read a lot of text. We are on the internet, however! So we need…

What we need…

• A short and precise way
• Easy UI, usable by everyone (just as the wonderful UX StreetComplete has, this solution has to be easy, too)
• Getting proposals into a common, well-structured form
• Requiring some thought from the user
• Clearly documenting the requirements

The solution(?)

• separate bug tracker/repo?
• in-app mechanism or own website or third-party mechanism
• staying on GitHub, but making it easier for people to suggest quests properly
• close all proposals for quests immediately

How?

• separate -> easy (move StreetComplete to organisation, new "issue-only" repo), advantage unclear (Quests are still there, may still be wrong)
• extra website* -> hard (needs development), advantage depends (on how it is done)
• third-party service* -> medium (needs thought/selection. UserVoice, maybe? Or some survey portal, where you can go through the requirements one by one? Or Discourse, with it's approach to "let the community manage themselves"?), advantage depends (e.g. is uservoice really better than GitHub?)
• stay on GitHub -> Ticklist with short description for quests, which users proposing quests have to go through -> easy (just an issue template with ticklist similar to this one), advantage depends (how effective is that template?)
• close proposals -> rude, not in the faith of FLOSS, destroys community, frightens potential contributors, i.e. no solution; advantage: nothing

* extra advantage: users do not have to be on GitHub for proposing quests

Of course, I am biased. (I would suggest the ticklist as an issue template, and also include a template part for letting the user think about the UI)
Of course the proposals could be combined. E.g. the issue template with the ticklist can be in a new repo, specialized for that.

[Binnette]

Start by adding a "pattern" on the wiki : "how to propose new quest"
(Please fill the fields below)
Quest name = ..................
Quest question = ..............
Quest type = yes/no ; choose one ; multiple choice ; input tag value ; hour
Osm attributes = attr1 with link ; attr2 with link

Also you can provide a table like mine for "choose one/choose multiple"

Choose one :	attr1	attr2
Answer1	val1	val1b
Answer2	val2
Answer3	val3	val3b
Other answer...
Answer4	val4

Also you can add on wiki a screenhot for every quest type : yes/no, choose one, ...

[chrisdebian]

This is much more aligned to FOSS. I think it's fine if people suggest quests, without all the needed information; if we rely on people knowing everything, as stated, it will frighten people away. In my experience, it's also a good idea to list key people, so if less experienced people need help, they can ask better targeted questions. This would normally be a simple table, or listing; this is an example that I was part of, a while ago: http://www.gnewsense.org/Credits?action=show&redirect=WhoHacksWhat#toc12 Tobias would obviously be BDFL, for as long as he wants to be, but organising the supporting team, will help. Just my thoughts, Chris chris_debian

…

On Sun, 27 Aug 2017, 14:31 Binnette ***@***.***> wrote: Start by adding a "pattern" on the wiki : "how to propose new quest" (Please fill the fields below) Quest name = .................. Quest question = .............. Quest type = yes/no ; choose one ; multiple choice ; input tag value ; hour Osm attributes = attr1 with link ; attr2 with link Also you can provide a table like mine for "choose one/choose multiple" Choose one : attr1 attr2 Answer1 val1 val1b Answer2 val2 Answer3 val3 val3b Other answer... Answer4 val4 Also you can add on wiki a screenhot for every quest type : yes/no, choose one, ... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#550 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARGrd4OgrNV4A-ruu0UjctPfqOqgEh6xks5scW_BgaJpZM4PDyzc> .

[rugk]

In my experience, it's also a good idea to list key people

Ehmm, who?
So you think about adding contributors (or "issue maintainers") to the project. Yes, an idea, clearly…
Edit: Indeed that "issue maintainer" thing could be easier when in a new repo. There, then, some people can get "commit access" (just for managing the issues) without having access to the main repo.

Start by adding a "pattern" on the wiki

The wiki is still too far away when clicking on the "new issue" button. So an issue template would be suitable here. Also, there, you can immediately fill it out and don't need to copy & paste things.

if we rely on people knowing everything, as stated, it will frighten people away.

Hmm, yeah, but I'd want to make it easier anyway. And get people to think about it to facilitate the work for @westnordost.
I think, we don't have to require people to know/have ideas about all the information. We can give a note at the top "Fill out the following template as best as you can. If you cannot fill out an entry, leave it out and we'll try to find it.".

However when proposing a quest they should be able to know certain things. I mean, they don't have to provide an overpass query, but at least they should be able to describe it roughly in words and mention the tag they talk about. And they should know, why the information added in a quest is useful, etc. These are just basic things and this might make such issues more useful.

[westnordost]

@rugk It is very thoughtful of you to write this, thank you for that. I will answer more detailed later.

[westnordost]

I improved the https://github.com/westnordost/StreetComplete/wiki/Adding-new-Quests-to-StreetComplete guide, made the initial section a bit more friendly to read and added some stuff I recently wrote into (your) tickets.

Let's do the tick list! Because:

• it's easiest
• even if there was some separate portal, new people will still continue to post things here, I don't think it can be stopped / completely diverted to another place. So then might as well deal with it via the github issue tracker

[westnordost]

I did that now. Added this tick list.

[rugk]

Oh, wow. How… nice. So I see that constructive feedback always wins! 😎

And using Emojis is an awesome idea. 👍

So now just get into the details (note I would gladly do a PR on that):

1. First, I would add a note at the top stating that this template of course only applies if you suggest a quest. To obvious, but people also create "usual" bug reports here. So maybe
   (Tip: Add things, whcih should not be displayed when the issue is done in HTML comments <!-- … -->.)
2. Another note: "If the answer is not obvious, please append a short explanation to each item, explaining the reason."; Background: It is always good to give reasons for the decisions there as otherwise things may still be unclear. E.g. the "Useful purpose" should definitively be proved.
3. May we split "tag is established, has a useful purpose". IMHO these are two criteria. A tag can be established/common (based on the number of uses taginfo shows), but may still be just some silly thing nobody uses or no application uses
4. "Always definitely answerable" – There is still a way to leave a note, so better: "In almost all cases definitely answerable with proposed selection"
5. "No spam", sounds a bit colloquial and not specific enough, but I have not a better idea too, right now. Okay, maybe reword it: "Asking it for every element creates no spam (not an enormous amount of quests answerable with the same answer)". (part in brackets optional) That's easily checkable.
6. "Easily answerable by everyone and from the public outside". (or "without entering") "Public" is not clear. ("and" is not needed here too)
7. The criteria "It can be determined, if the quest is needed to be asked." E.g. that's not possible for quests for some stupid tags where you cannot set "no". So the quest would in some cases always re-appear. I think we had some cases here…
8. I would go further and add some stuff for step 2 and 3 from your guide to the template. (similar to what @Binnette proposed). Of course, this part needs to be marked as optional as an issue creator does not (yet) need to think about how the quest is implemented and other details, but may does that to simplify the whole task.
   And BTW: Personally I also find it easier to first think about the form and then think about how we may limit the selection in an Overpass query. But that may just be a personal preference.

[rugk]

Maybe we can simplify the wording of the "Always definitely answerable"/nospam and the "Applies to a reasonable number of elements"/efford criteria to: "There are not too few possible quests" and "There are not too many unnecessary quests". Although we should keep in mind that this is something, which also depends on the implementation and this is something the average user should not always have to think up to the end.

[westnordost]

4. / 7.

That's just the short form, the longer explanation should be clearer on what is meant specifically because an example is given there: Any answer outside of the sphere of "cannot answer because quest is invalid / place does not exist anymore".
Changed to "Any answer the user can give must have an equivalent tagging (No false-positives) "

Yeah, I don't know, I don't want to add too much template there, as this may lead to people just filling out the required parts and not think for themselves and confuse people who do not want to add a quest suggestion bug report a bug or something else.
So, I want to leave it at this checklist for now.

[westnordost]

Check again, I changed the wording.

[rugk]

Yeah, that nis much better.

9. I just don't get what "answerable by everyone from the outside" has to do with an "Easy UI". That are two criterias for me. The one is AFK/offline/IRL and the other one is a pure software thing, so…

As for 8. I can set a PR. (I would also do 1./2. there, then)

Still 3. is open. Don't you think it is useful to split established and useful purpose?

[westnordost]

No, I think these are related. If a tag is not established, it is even more important that it has a useful purpose. The more useful the purpose, the less important it is that it is already well established. So I mention them in the same sentence.

You can, but I cannot guarantee that I will pull it. I am not too convinced that this is necessary / helpful.

Removed "Easy UI".

[rugk]

Another suggestion: Mostly for the "has a useful purpose" I think, it is too few to just let the issue creator tick a box and (optionally) add a reason.
Because IMHO, that could be a condition where you always need to explain what purpose it provides/why it is useful. So maybe better add a line "Why is this quest useful for OSM/StreetComplete? How is the tagged information you add, consumed by other people or applications?"?

[westnordost]

So no checkboxes but questions?

[rugk]

No checkboxes are okay for simple items, but maybe for this one question… Or maybe just require a reason below the checkbox part, so people don't have to pack that part into the line, where the checkbox is.

(But, we can also leave it as it is. I already like it. And people should just write some reasoning below the part by themselves.)