Re: [WikimediaMobile] Task/bug naming conventions
I've always used enhancement for this purpose -- does phabricator actually support this? On Mon, Jun 8, 2015 at 10:33 AM, Gergo Tisza gti...@wikimedia.org wrote: Hi all, I would like to recommend a naming convention that clearly differentiates between existing and wanted behavior. This is something that has been confusing for me for a while - bugs and tasks are both in the indicative so I often have trouble deciding whether a ticket describes a situation that exists but should not or one that does not exist but should. Random example from current sprint board: Anon users can access public view from main menu with the associated description being When anonymous and I click collections I am taken to the public view. Does this mean that anonymous users should not be able to access the public view but somehow they can, or is this the description of a wanted feature? I can figure it out by digging up context, of course, but that takes time; ideally, this should be clear from just the task title (which I might be seeing in a list or on a workboard). I think it would be clearer if the title of the task would always reflected the situation at the time of creating the task, and titles describing a wanted but not currently existing state were phrased as imperatives. So if anons can see the public view right now and that's a bug the title would say anons can access public view; if they cannot access it currently but that's a feature we want, the title would say anons should be able to access public view or make anons able to access public view. Thoughts? ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Task/bug naming conventions
On 8 jun. 2015, at 19:52, Jon Katz jk...@wikimedia.org wrote: I think we could go a step further and call out bugs with the prefix bug: for more clarity. -J Please also discuss such a thing with Andre and other Phab people. We only just got rid of prefixes since we dumped bugzilla. It might be wise to make sure a sustainable route is chosen for any new conventions. DJ signature.asc Description: Message signed with OpenPGP using GPGMail ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [reading-wmf] Wikipedia article previews in Kindle app
Great find! Since we're mentioning similar features, the Google Dictionary
https://chrome.google.com/webstore/detail/google-dictionary-by-goog/mgijmajocgfcbeboacabfgobmjgjcoja
Chromium
/ Chrome extension (by Google) performs a similar function.
[image: Inline image 1]
--stephen
On Mon, Jun 8, 2015 at 2:04 AM, S Page sp...@wikimedia.org wrote:
On Thu, Jun 4, 2015 at 10:45 PM, Dmitry Brant dbr...@wikimedia.org
wrote:
(I wonder what API they're using?)
api.log logs all API requests, but doesn't include referer.
Cross-referencing warnings in api-feature-usage (below) suggests at least
some requests like
action=query format=json titles=dotage redirects= prop=revisions
rvprop=content rvlimit=1 rvsection=0
followed by
action=parse format=json title=Dotage
text=%7B%7Bwiktionary%20redirect%7D%7D%7B%7BShort%20pages%20monitor%7D%7D
(the Dotage article returns a rather unhelpful {{wiktionary
redirect}}{{Short pages monitor}}).
So Kindle sometimes retrieves the wikitext of the zero section of the
article, then requests a parse of it. Using TextExtracts would be so much
better, prop=extractsexintro= would give similar info in a single API call.
On Fri, Jun 5, 2015 at 7:39 AM, Bernd Sitzmann be...@wikimedia.org
wrote:
Nice find. I also like being able to swipe those cards left/right between
different information sources. Looks like depending on the selected words
it's: Dictionary, Wikipedia, Translation
That is awesome. Link preview and Hovercards should do the same, we do
little to surface content in the non-pedia wikis beyond {{Sister project
links}} at the bottom of some articles. (Hovercards would have a row of
icons as well as the swipe gesture).
Which raises the question where should I phile a Reading proposal like
that, rather than for each app's implementation of link preview and
hovercards?
[Apple's OS-level integration]]
Link preview and Hovercards work on a link. But wikis intentionally only
link the first use of a term and don't link every term per MOS:
overlinking
https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Linking#Overlinking,
which means I often scroll backwards searching for the first mention of a
term. It would be nice if there were an affordance to be able to lookup any
text, even if not explicitly linked.
Maybe WMF should offer its own browser- or OS-level integration, pushing
the reading experience way beyond our sites.
https://en.wikipedia.org/wiki/Wikipedia:Tools/Browser_tools lists various
browser addons, such as Lookup companion for Wiki
https://chrome.google.com/webstore/detail/lookup-companion-for-wiki/dhgpkiiipkgmckicafkhcihkcldbdeej?hl=en
that do this. Meanwhile
https://en.wikipedia.org/wiki/Wikipedia:Tools#Searching has Download
1-Click Answers Wikipedia Edition for Windows (beta) and then Alt-Click on
any word in any program on your screen for instant, accurate facts. Who
knew?!, makes me want to bust out Windows 2000 :)
On Fri, Jun 5, 2015 at 10:59 AM, Joaquin Oltra Hernandez
jhernan...@wikimedia.org wrote:
I wonder what will happen if one of our breaking api changes [breaks] one
of these queries... They are probably running a proxy cached service to
avoid any of those problems.
Good point. I'll forward to Kourosh, who deals with partnerships like
this, and we can only hope people writing all these tools are on some
mailing list.
fluorine:/a/mw-logs/api-feature-usage.log has a number of
2015-06-07 06:26:39 mw1232 enwiki api-feature-usage INFO:
action=query!rawcontinue!continue from user agents containing Kindle.
ApiQuery.php logs this along with the warning in the API result Formatting
of continuation data will be changing soon. ...
So I hope someone notices the warnings in API responses.
--
=S Page WMF Tech writer
___
reading-wmf mailing list
reading-...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/reading-wmf
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Task/bug naming conventions
Good call, Gergo, and for calling out crap when you see it. I know I am to blame on a lot of these (including the above example). I think the language solution you described is pretty good. restating suggested rules for those who don't read prose: - bugs--explain bad state in present tense (and desired state in description if nec). Users screen goes blank - enhancement--explain desired state as imperative Make it so users can.. or Users should be able to... I think we could go a step further and call out bugs with the prefix bug: for more clarity. -J On Mon, Jun 8, 2015 at 10:38 AM, Jeff Hobson jhob...@wikimedia.org wrote: +1, also any bugs should have clear repro steps in description and wanted features should have a clear UX path/outlined steps. Thanks, Jeff Hobson On Jun 8, 2015 1:33 PM, Gergo Tisza gti...@wikimedia.org wrote: Hi all, I would like to recommend a naming convention that clearly differentiates between existing and wanted behavior. This is something that has been confusing for me for a while - bugs and tasks are both in the indicative so I often have trouble deciding whether a ticket describes a situation that exists but should not or one that does not exist but should. Random example from current sprint board: Anon users can access public view from main menu with the associated description being When anonymous and I click collections I am taken to the public view. Does this mean that anonymous users should not be able to access the public view but somehow they can, or is this the description of a wanted feature? I can figure it out by digging up context, of course, but that takes time; ideally, this should be clear from just the task title (which I might be seeing in a list or on a workboard). I think it would be clearer if the title of the task would always reflected the situation at the time of creating the task, and titles describing a wanted but not currently existing state were phrased as imperatives. So if anons can see the public view right now and that's a bug the title would say anons can access public view; if they cannot access it currently but that's a feature we want, the title would say anons should be able to access public view or make anons able to access public view. Thoughts? ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [reading-wmf] Wikipedia article previews in Kindle app
On Mon, Jun 8, 2015 at 1:04 AM, S Page sp...@wikimedia.org wrote: Maybe WMF should offer its own browser- or OS-level integration, pushing the reading experience way beyond our sites. https://en.wikipedia.org/wiki/Wikipedia:Tools/Browser_tools lists various browser addons, such as Lookup companion for Wiki https://chrome.google.com/webstore/detail/lookup-companion-for-wiki/dhgpkiiipkgmckicafkhcihkcldbdeej?hl=en that do this. Meanwhile https://en.wikipedia.org/wiki/Wikipedia:Tools#Searching has Download 1-Click Answers Wikipedia Edition for Windows (beta) and then Alt-Click on any word in any program on your screen for instant, accurate facts. Who knew?!, makes me want to bust out Windows 2000 :) A WMF-maintained self-contained javascript library to fetch Wikipedia summaries / Wikidata descriptions / Wikitionary translations (and maybe even Commons images) for a given string and display them in a configurable popup window would be awesome. That could then be used as a bookmarklet, in browser extensions (most of those are written in JS so they just need a trivial wrapper around the library), or in web pages as a functionality provided by the site owner. ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Task/bug naming conventions
It might be easier to tag enhancements with enh: given that anyone can create tasks and will not necessarily adhere to our standards. This would at least solve confusion in whether things are bugs or enhancements. On Mon, Jun 8, 2015 at 10:52 AM, Jon Katz jk...@wikimedia.org wrote: Good call, Gergo, and for calling out crap when you see it. I know I am to blame on a lot of these (including the above example). I think the language solution you described is pretty good. restating suggested rules for those who don't read prose: - bugs--explain bad state in present tense (and desired state in description if nec). Users screen goes blank - enhancement--explain desired state as imperative Make it so users can.. or Users should be able to... I think we could go a step further and call out bugs with the prefix bug: for more clarity. -J On Mon, Jun 8, 2015 at 10:38 AM, Jeff Hobson jhob...@wikimedia.org wrote: +1, also any bugs should have clear repro steps in description and wanted features should have a clear UX path/outlined steps. Thanks, Jeff Hobson On Jun 8, 2015 1:33 PM, Gergo Tisza gti...@wikimedia.org wrote: Hi all, I would like to recommend a naming convention that clearly differentiates between existing and wanted behavior. This is something that has been confusing for me for a while - bugs and tasks are both in the indicative so I often have trouble deciding whether a ticket describes a situation that exists but should not or one that does not exist but should. Random example from current sprint board: Anon users can access public view from main menu with the associated description being When anonymous and I click collections I am taken to the public view. Does this mean that anonymous users should not be able to access the public view but somehow they can, or is this the description of a wanted feature? I can figure it out by digging up context, of course, but that takes time; ideally, this should be clear from just the task title (which I might be seeing in a list or on a workboard). I think it would be clearer if the title of the task would always reflected the situation at the time of creating the task, and titles describing a wanted but not currently existing state were phrased as imperatives. So if anons can see the public view right now and that's a bug the title would say anons can access public view; if they cannot access it currently but that's a feature we want, the title would say anons should be able to access public view or make anons able to access public view. Thoughts? ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Task/bug naming conventions
We made a bug ticket template that clearly asks for both “Actual Results” and “Expected Results” to help with this. T98466 https://phabricator.wikimedia.org/T98466 On Mon, Jun 8, 2015 at 2:25 PM, Derk-Jan Hartman d.j.hartman+wmf...@gmail.com wrote: On 8 jun. 2015, at 19:52, Jon Katz jk...@wikimedia.org wrote: I think we could go a step further and call out bugs with the prefix bug: for more clarity. -J Please also discuss such a thing with Andre and other Phab people. We only just got rid of prefixes since we dumped bugzilla. It might be wise to make sure a sustainable route is chosen for any new conventions. DJ ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] [reading-wmf] Wikipedia article previews in Kindle app
+ Kouroush A summary of ideas: *WP as destination:* -Sister projects swipable from cards -WMF owned OS integration/browser add-ons *WP as platform:* -API for 'cards' on topics/JS library -Make sure API changes aren't breaking experience for: apple, google, amazon? -Help kindle optimize their calls -Key partner list...do we have this for major integrations? These are great ideas, and I don't want to lose them. What should go on the brainstorming etherboard for Q1 https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm and what should go elsewhere (and how do we make sure elsewhere isn't purgatory). -J On Mon, Jun 8, 2015 at 11:34 AM, Gergo Tisza gti...@wikimedia.org wrote: On Mon, Jun 8, 2015 at 1:04 AM, S Page sp...@wikimedia.org wrote: Maybe WMF should offer its own browser- or OS-level integration, pushing the reading experience way beyond our sites. https://en.wikipedia.org/wiki/Wikipedia:Tools/Browser_tools lists various browser addons, such as Lookup companion for Wiki https://chrome.google.com/webstore/detail/lookup-companion-for-wiki/dhgpkiiipkgmckicafkhcihkcldbdeej?hl=en that do this. Meanwhile https://en.wikipedia.org/wiki/Wikipedia:Tools#Searching has Download 1-Click Answers Wikipedia Edition for Windows (beta) and then Alt-Click on any word in any program on your screen for instant, accurate facts. Who knew?!, makes me want to bust out Windows 2000 :) A WMF-maintained self-contained javascript library to fetch Wikipedia summaries / Wikidata descriptions / Wikitionary translations (and maybe even Commons images) for a given string and display them in a configurable popup window would be awesome. That could then be used as a bookmarklet, in browser extensions (most of those are written in JS so they just need a trivial wrapper around the library), or in web pages as a functionality provided by the site owner. ___ reading-wmf mailing list reading-...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/reading-wmf ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[WikimediaMobile] Fwd: [Wikitech-l] Feedback requested on our search APIs
Cross posting. Please reply directly to Dan or use the wikitech-l list if responding. -Adam -- Forwarded message -- From: Dan Garry dga...@wikimedia.org Date: Mon, Jun 8, 2015 at 3:54 PM Subject: [Wikitech-l] Feedback requested on our search APIs To: Wikimedia developers wikitec...@lists.wikimedia.org Do you use our search API? If so, I'd like to hear from you! The Discovery Department https://wikimediafoundation.org/wiki/Staff_and_contractors#Discovery at the Wikimedia Foundation is tasked with building a path of discovery to relevant and trusted knowledge. In line with that, one of our primary responsibilities is to ensure that our search APIs are stable, fast, and easy to use. We'd love to hear from the people that are using our APIs, so we can learn what you love about them, what frustrates you, and what we can do to improve them for you. I'd prefer that you keep the comments about the API itself rather than the relevance of the results it returns; I plan to start a separate thread about the result relevance, since they're separate topics. If you have some feedback, please reply in this thread or reach out to me privately. Thanks! Dan -- Dan Garry Product Manager, Discovery Wikimedia Foundation ___ Wikitech-l mailing list wikitec...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
