(apologies for cross-posting)
I'm happy to announce that HHVM is available on all Wikimedia wikis for intrepid beta testers. HHVM, you'll recall, is an alternative runtime for PHP that provides substantial performance improvements over the standard PHP interpreter. Simply put: HHVM is software that runs on Wikimedia's servers to make your reading and editing experience faster.
You can read more about HHVM here: https://www.mediawiki.org/wiki/HHVM
* How do I enable HHVM?
You can enable HHVM by opting in to the beta feature. This short animated gif will show you how: http://people.wikimedia.org/~ori/hhvm_beta.gif.
Enabling the beta feature will set a special cookie in your browser. Our servers are configured to route requests bearing this cookie to a pool of servers that are running HHVM.
* How do I know that it's working?
Opting-in to the beta feature does not change the user interface in any way. If you like, you can copy the following code snippet to the global.js subpage of your user page on MetaWiki:
https://meta.wikimedia.org/wiki/User:Ori.livneh/global.js
If you copy this script to your global.js, the personal bar will be annotated with the name of the PHP runtime used to generate the page and the backend response time. It looks like this:
http://people.wikimedia.org/~ori/hhvm_script.png
Edits made by users with HHVM enabled will be tagged with 'HHVM'. The tag is there as a precaution, to help us clean up if we discover that HHVM is mangling edits somehow. We don't expect this to happen.
* What sort of performance changes should I expect?
We expect HHVM to have a substantial impact on the time it takes to load, preview, and save pages.
At the moment, API requests are not being handled by HHVM. Because VisualEditor uses the API to save articles, opting in to the HHVM beta feature will not impact the performance of VisualEditor. We hope to have HHVM handling API requests next week.
* What sort of issues might I encounter?
Most of the bugs that we have encountered so far resulted from minute differences in how PHP5 and HHVM handle various edge-cases. These bugs typically cause a MediaWiki error page to be shown.
If you encounter an error, please report it on Bugzilla and tag with it the 'HHVM' keyword.
We're not done yet, but this is an important milestone. The roll-out of HHVM as a beta feature caps many months of hard work from many developers, both salaried and volunteer, from the Wikimedia Foundation, Wikimedia Deutschland, and the broader Wikimedia movement. I want to take this opportunity to express my appreciation to the following individuals, listed in alphabetical order:
Aaron Schulz, Alexandros Kosiaris, Brad Jorsch, Brandon Black, Brett Simmers, Bryan Davis, Chad Horohoe, Chris Steipp, Erik Bernhardson, Erik Möller, Faidon Liambotis, Filippo Giunchedi, Giuseppe Lavagetto, Greg Grossmeier, Jack McBarn, Katie Filbert, Kunal Mehta, Mark Bergsma, Max Semenik, Niklas Laxström, Rob Lanphier, and Tim Starling.
More good things to come! :)
Ori and ...
Aaron Schulz, Alexandros Kosiaris, Brad Jorsch, Brandon Black, Brett Simmers, Bryan Davis, Chad Horohoe, Chris Steipp, Erik Bernhardson, Faidon Liambotis, Filippo Giunchedi, Giuseppe Lavagetto, Greg Grossmeier, Jack McBarn, Katie Filbert, Kunal Mehta, Mark Bergsma, Max Semenik, Niklas Laxström, Rob Lanphier, and Tim Starling.
.. amazing work, everyone. This is a huge milestone and it's wonderful to see the finish line come closer. Making and keeping our sites fast is hugely important, and all evidence so far suggests that HHVM will be one of the biggest gains ever. :)
Please, do help spread the word and give it a spin, as we iron out remaining issues.
Erik
I experienced no improved answer time, but all time stamps in Wikipedia for me become wrong making it impossible to use the feature. I would call this problem a thing that should have been found in an alpha text... Anders
Ori Livneh skrev 2014-09-19 03:39:
(apologies for cross-posting)
I'm happy to announce that HHVM is available on all Wikimedia wikis for intrepid beta testers. HHVM, you'll recall, is an alternative runtime for PHP that provides substantial performance improvements over the standard PHP interpreter. Simply put: HHVM is software that runs on Wikimedia's servers to make your reading and editing experience faster.
You can read more about HHVM here: https://www.mediawiki.org/wiki/HHVM
- How do I enable HHVM?
You can enable HHVM by opting in to the beta feature. This short animated gif will show you how: http://people.wikimedia.org/~ori/hhvm_beta.gif.
Enabling the beta feature will set a special cookie in your browser. Our servers are configured to route requests bearing this cookie to a pool of servers that are running HHVM.
- How do I know that it's working?
Opting-in to the beta feature does not change the user interface in any way. If you like, you can copy the following code snippet to the global.js subpage of your user page on MetaWiki:
https://meta.wikimedia.org/wiki/User:Ori.livneh/global.js
If you copy this script to your global.js, the personal bar will be annotated with the name of the PHP runtime used to generate the page and the backend response time. It looks like this:
http://people.wikimedia.org/~ori/hhvm_script.png
Edits made by users with HHVM enabled will be tagged with 'HHVM'. The tag is there as a precaution, to help us clean up if we discover that HHVM is mangling edits somehow. We don't expect this to happen.
- What sort of performance changes should I expect?
We expect HHVM to have a substantial impact on the time it takes to load, preview, and save pages.
At the moment, API requests are not being handled by HHVM. Because VisualEditor uses the API to save articles, opting in to the HHVM beta feature will not impact the performance of VisualEditor. We hope to have HHVM handling API requests next week.
- What sort of issues might I encounter?
Most of the bugs that we have encountered so far resulted from minute differences in how PHP5 and HHVM handle various edge-cases. These bugs typically cause a MediaWiki error page to be shown.
If you encounter an error, please report it on Bugzilla and tag with it the 'HHVM' keyword.
We're not done yet, but this is an important milestone. The roll-out of HHVM as a beta feature caps many months of hard work from many developers, both salaried and volunteer, from the Wikimedia Foundation, Wikimedia Deutschland, and the broader Wikimedia movement. I want to take this opportunity to express my appreciation to the following individuals, listed in alphabetical order:
Aaron Schulz, Alexandros Kosiaris, Brad Jorsch, Brandon Black, Brett Simmers, Bryan Davis, Chad Horohoe, Chris Steipp, Erik Bernhardson, Erik Möller, Faidon Liambotis, Filippo Giunchedi, Giuseppe Lavagetto, Greg Grossmeier, Jack McBarn, Katie Filbert, Kunal Mehta, Mark Bergsma, Max Semenik, Niklas Laxström, Rob Lanphier, and Tim Starling.
More good things to come! :) _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Fri, Sep 19, 2014 at 12:22 AM, Anders Wennersten < mail@anderswennersten.se> wrote:
I experienced no improved answer time, but all time stamps in Wikipedia for me become wrong making it impossible to use the feature. I would call this problem a thing that should have been found in an alpha text... Anders
Hi Anders,
Thanks for trying it out. Could you clarify what you mean? I don't see anything wrong, but I'm not very observant. If you're comparing the logged-in and logged-out views, did you remember to take into account the timezone offset preference (if set)?
It has to do with timezone preferences. All times in latest changes and in my edits states time two hour wrong
In am not sure what you mean with take timezone into account, I just clicked into the box as stated in your mail, and then all times changed, and when I took off the feature all times went back to correct time
Anders
Ori Livneh skrev 2014-09-19 09:46:
On Fri, Sep 19, 2014 at 12:22 AM, Anders Wennersten < mail@anderswennersten.se> wrote:
I experienced no improved answer time, but all time stamps in Wikipedia for me become wrong making it impossible to use the feature. I would call this problem a thing that should have been found in an alpha text... Anders
Hi Anders,
Thanks for trying it out. Could you clarify what you mean? I don't see anything wrong, but I'm not very observant. If you're comparing the logged-in and logged-out views, did you remember to take into account the timezone offset preference (if set)? _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Yeah, I can confirm this.
It appears that when you turn on HHVM it forces the default time setting to be UTC, so if you're on a wiki which uses a non UTC default time zone (usually the time zone of the region most using the language, we do this on around 200 wikis) suddenly all of the times you are used to seeing (in the history, recent changes, contributions, signature time stamps etc) change what time they are showing which gets confusing.
This does not appear to happen if you have 'manually' set your time zone (only if you are using the local default).
I'm going to file a bug now for it assuming someone else hasn't.
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Fri, Sep 19, 2014 at 1:35 AM, Anders Wennersten <mail@anderswennersten.se
wrote:
It has to do with timezone preferences. All times in latest changes and in my edits states time two hour wrong
In am not sure what you mean with take timezone into account, I just clicked into the box as stated in your mail, and then all times changed, and when I took off the feature all times went back to correct time
Anders
Ori Livneh skrev 2014-09-19 09:46:
On Fri, Sep 19, 2014 at 12:22 AM, Anders Wennersten <
mail@anderswennersten.se> wrote:
I experienced no improved answer time, but all time stamps in Wikipedia
for me become wrong making it impossible to use the feature. I would call this problem a thing that should have been found in an alpha text... Anders
Hi Anders,
Thanks for trying it out. Could you clarify what you mean? I don't see anything wrong, but I'm not very observant. If you're comparing the logged-in and logged-out views, did you remember to take into account the timezone offset preference (if set)? _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Bug filed at: https://bugzilla.wikimedia.org/show_bug.cgi?id=71036
To correct myself: It does NOT appear that the signature time zone is affected, that is always the local wiki default as defined in http://noc.wikimedia.org/conf/InitialiseSettings.php.txt no matter what you set in appearances.
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Fri, Sep 19, 2014 at 2:02 AM, James Alexander jalexander@wikimedia.org wrote:
Yeah, I can confirm this.
It appears that when you turn on HHVM it forces the default time setting to be UTC, so if you're on a wiki which uses a non UTC default time zone (usually the time zone of the region most using the language, we do this on around 200 wikis) suddenly all of the times you are used to seeing (in the history, recent changes, contributions, signature time stamps etc) change what time they are showing which gets confusing.
This does not appear to happen if you have 'manually' set your time zone (only if you are using the local default).
I'm going to file a bug now for it assuming someone else hasn't.
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Fri, Sep 19, 2014 at 1:35 AM, Anders Wennersten < mail@anderswennersten.se> wrote:
It has to do with timezone preferences. All times in latest changes and in my edits states time two hour wrong
In am not sure what you mean with take timezone into account, I just clicked into the box as stated in your mail, and then all times changed, and when I took off the feature all times went back to correct time
Anders
Ori Livneh skrev 2014-09-19 09:46:
On Fri, Sep 19, 2014 at 12:22 AM, Anders Wennersten <
mail@anderswennersten.se> wrote:
I experienced no improved answer time, but all time stamps in Wikipedia
for me become wrong making it impossible to use the feature. I would call this problem a thing that should have been found in an alpha text... Anders
Hi Anders,
Thanks for trying it out. Could you clarify what you mean? I don't see anything wrong, but I'm not very observant. If you're comparing the logged-in and logged-out views, did you remember to take into account the timezone offset preference (if set)? _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Thanks!, glad you could sort this out and file a bug
But really, I understand from this that this feature was released as a Beta feature without it ever been tried out on any other project then enwp, which for me indicate a proper process for Alpha test before release to beta as been missing...
The very heated discussions of MV and Visual editor are much related to the fact that their quality and functionality at the time of full release was more of a state appropriate for a Beta release, The discsion has also clearly taken up the need of improvements of the deployment process.
It therefore make me concerned (much more than the bug as such involved here) to see that WMF still seems to have dysfunctional deployment processes.
I do hope to see, very soon, marked improvements in the software process.
Anders
James Alexander skrev 2014-09-19 11:27:
Bug filed at: https://bugzilla.wikimedia.org/show_bug.cgi?id=71036
To correct myself: It does NOT appear that the signature time zone is affected, that is always the local wiki default as defined in http://noc.wikimedia.org/conf/InitialiseSettings.php.txt no matter what you set in appearances.
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Fri, Sep 19, 2014 at 2:02 AM, James Alexander jalexander@wikimedia.org wrote:
Yeah, I can confirm this.
It appears that when you turn on HHVM it forces the default time setting to be UTC, so if you're on a wiki which uses a non UTC default time zone (usually the time zone of the region most using the language, we do this on around 200 wikis) suddenly all of the times you are used to seeing (in the history, recent changes, contributions, signature time stamps etc) change what time they are showing which gets confusing.
This does not appear to happen if you have 'manually' set your time zone (only if you are using the local default).
I'm going to file a bug now for it assuming someone else hasn't.
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Fri, Sep 19, 2014 at 1:35 AM, Anders Wennersten < mail@anderswennersten.se> wrote:
It has to do with timezone preferences. All times in latest changes and in my edits states time two hour wrong
In am not sure what you mean with take timezone into account, I just clicked into the box as stated in your mail, and then all times changed, and when I took off the feature all times went back to correct time
Anders
Ori Livneh skrev 2014-09-19 09:46:
On Fri, Sep 19, 2014 at 12:22 AM, Anders Wennersten <
mail@anderswennersten.se> wrote:
I experienced no improved answer time, but all time stamps in Wikipedia
for me become wrong making it impossible to use the feature. I would call this problem a thing that should have been found in an alpha text... Anders
Hi Anders,
Thanks for trying it out. Could you clarify what you mean? I don't see anything wrong, but I'm not very observant. If you're comparing the logged-in and logged-out views, did you remember to take into account the timezone offset preference (if set)? _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Fri, Sep 19, 2014 at 3:14 AM, Anders Wennersten <mail@anderswennersten.se
wrote:
Thanks!, glad you could sort this out and file a bug
But really, I understand from this that this feature was released as a Beta feature without it ever been tried out on any other project then enwp, which for me indicate a proper process for Alpha test before release to beta as been missing...
Sorry, I don't agree! I think the process worked very well just now. You're not giving yourself enough credit, I'm afraid :)
Why should he give himself credit for your insufficient testing? Am 19.09.2014 12:19 schrieb "Ori Livneh" ori@wikimedia.org:
On Fri, Sep 19, 2014 at 3:14 AM, Anders Wennersten < mail@anderswennersten.se
wrote:
Thanks!, glad you could sort this out and file a bug
But really, I understand from this that this feature was released as a Beta feature without it ever been tried out on any other project then
enwp,
which for me indicate a proper process for Alpha test before release to beta as been missing...
Sorry, I don't agree! I think the process worked very well just now. You're not giving yourself enough credit, I'm afraid :) _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hi,
On Fri, Sep 19, 2014 at 1:15 PM, MF-Warburg mfwarburg@googlemail.com wrote:
Why should he give himself credit for your insufficient testing?
"Insufficient" is in the eyes of the beholder :) Beta Features are experimental, and Ori's announcement clearly indicated that this particular feature was "for intrepid beta testers".
This means that the feature is still being tested, and that people who enable it should expect to find bugs, and should report them so they can be fixed before the feature is deployed more widely.
This is precisely what happened in this case, so the testing process worked as expected. Developers can't find All The Bugs alone, which is why they need the help of volunteer testers.
This was testing done right. The feature was offered as opt in and clearly marked as beta. A bug was found and quickly fixed. When you're testing beta software, you have to expect bugs.
We've been quick enough to knock rollouts done poorly or made default with inadequate testing, and should be. Let's not knock the ones done right. On Sep 19, 2014 5:24 AM, "Guillaume Paumier" gpaumier@wikimedia.org wrote:
Hi,
On Fri, Sep 19, 2014 at 1:15 PM, MF-Warburg mfwarburg@googlemail.com wrote:
Why should he give himself credit for your insufficient testing?
"Insufficient" is in the eyes of the beholder :) Beta Features are experimental, and Ori's announcement clearly indicated that this particular feature was "for intrepid beta testers".
This means that the feature is still being tested, and that people who enable it should expect to find bugs, and should report them so they can be fixed before the feature is deployed more widely.
This is precisely what happened in this case, so the testing process worked as expected. Developers can't find All The Bugs alone, which is why they need the help of volunteer testers.
-- Guillaume Paumier
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Friday, 19 September 2014, Todd Allen toddmallen@gmail.com wrote:
This was testing done right. The feature was offered as opt in and clearly marked as beta.
This genuinely is testing done right. HHVM has been on the beta cluster for a few months and has been enabled on testwiki by default for a month. In addition it has been opt-in on production for a week or two already. This is purely an easy way for people to test as the other way was, sort of annoying :)
John Lewis
It now works as it should, thanks for a quick fix!
I also did soma very subjective test on response times and found the new feature to give 1-3 s quicker response, which is quite much (6s-5s, 7s-4s) and make a big difference in the user experience.
So many thanks for deploying such a good feature.
Also after reflecting on my little harsh reaction on the deployment process, I wonder if it is not a language/communication issue
Being a non-native English speaking person I must admit I have no idea of the meaning "intrepid" means in "for intrepid beta testers". It seems for Guillaume it means "hey this is badly tested, but use if you have patience/courage" which I can accept as a message of a testrelease
Also in my backgroud working in a company making internal deployment of software for 4000 internal users, I am used of making a huge difference in "ready for Alpha test" and "ready for Beta test", but perhaps my reference frame is inappropriate in this case, where perhaps a beta functionality means "Software for testing, not ready for release" and covering both my distinctions
So I apologize if I used too strong wordings and instead want to congratulate you on releasing a good function where you so speedily fixed the bug!
Anders
Ori Livneh skrev 2014-09-19 12:18:
On Fri, Sep 19, 2014 at 3:14 AM, Anders Wennersten <mail@anderswennersten.se
wrote: Thanks!, glad you could sort this out and file a bug
But really, I understand from this that this feature was released as a Beta feature without it ever been tried out on any other project then enwp, which for me indicate a proper process for Alpha test before release to beta as been missing...
Sorry, I don't agree! I think the process worked very well just now. You're not giving yourself enough credit, I'm afraid :) _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Anders Wennersten wrote:
I also did soma very subjective test on response times and found the new feature to give 1-3 s quicker response, which is quite much (6s-5s, 7s-4s) and make a big difference in the user experience.
Woo! :D
Also after reflecting on my little harsh reaction on the deployment process, I wonder if it is not a language/communication issue
Being a non-native English speaking person I must admit I have no idea of the meaning "intrepid" means in "for intrepid beta testers". It seems for Guillaume it means "hey this is badly tested, but use if you have patience/courage" which I can accept as a message of a testrelease
Also in my backgroud working in a company making internal deployment of software for 4000 internal users, I am used of making a huge difference in "ready for Alpha test" and "ready for Beta test", but perhaps my reference frame is inappropriate in this case, where perhaps a beta functionality means "Software for testing, not ready for release" and covering both my distinctions
So I apologize if I used too strong wordings and instead want to congratulate you on releasing a good function where you so speedily fixed the bug!
No worries. Thank you for taking the time to write up this message explaining. I think there are definitely ways in which we can improve our communication about beta (or alpha!) features, including attempting to label them appropriately and making sure the message is suitably clear. Your constructive feedback will help us do better in the future.
MZMcBride
:} I am always impressed by those of you for whom English is not your native tongue. It can be very complicated to understand some of the shortcuts we use.
Sent from my iPad
On 20 Sep 2014, at 02:22, MZMcBride z@mzmcbride.com wrote:
Anders Wennersten wrote:
I also did soma very subjective test on response times and found the new feature to give 1-3 s quicker response, which is quite much (6s-5s, 7s-4s) and make a big difference in the user experience.
Woo! :D
Also after reflecting on my little harsh reaction on the deployment process, I wonder if it is not a language/communication issue
Being a non-native English speaking person I must admit I have no idea of the meaning "intrepid" means in "for intrepid beta testers". It seems for Guillaume it means "hey this is badly tested, but use if you have patience/courage" which I can accept as a message of a testrelease
Also in my backgroud working in a company making internal deployment of software for 4000 internal users, I am used of making a huge difference in "ready for Alpha test" and "ready for Beta test", but perhaps my reference frame is inappropriate in this case, where perhaps a beta functionality means "Software for testing, not ready for release" and covering both my distinctions
So I apologize if I used too strong wordings and instead want to congratulate you on releasing a good function where you so speedily fixed the bug!
No worries. Thank you for taking the time to write up this message explaining. I think there are definitely ways in which we can improve our communication about beta (or alpha!) features, including attempting to label them appropriately and making sure the message is suitably clear. Your constructive feedback will help us do better in the future.
MZMcBride
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Do we have a published guideline somewhere about MediaWiki quality standards for pre-alpha, alpha, beta, and production releases of elements like MediaViewer, VisualEditor, Flow, Winter, and HHVM?
Pine On Sep 20, 2014 12:14 AM, "Jon Work" jon.davies@wikimedia.org.uk wrote:
:} I am always impressed by those of you for whom English is not your native tongue. It can be very complicated to understand some of the shortcuts we use.
Sent from my iPad
On 20 Sep 2014, at 02:22, MZMcBride z@mzmcbride.com wrote:
Anders Wennersten wrote:
I also did soma very subjective test on response times and found the new feature to give 1-3 s quicker response, which is quite much (6s-5s, 7s-4s) and make a big difference in the user experience.
Woo! :D
Also after reflecting on my little harsh reaction on the deployment process, I wonder if it is not a language/communication issue
Being a non-native English speaking person I must admit I have no idea of the meaning "intrepid" means in "for intrepid beta testers". It seems for Guillaume it means "hey this is badly tested, but use if you have patience/courage" which I can accept as a message of a testrelease
Also in my backgroud working in a company making internal deployment of software for 4000 internal users, I am used of making a huge difference in "ready for Alpha test" and "ready for Beta test", but perhaps my reference frame is inappropriate in this case, where perhaps a beta functionality means "Software for testing, not ready for release" and covering both my distinctions
So I apologize if I used too strong wordings and instead want to congratulate you on releasing a good function where you so speedily fixed the bug!
No worries. Thank you for taking the time to write up this message explaining. I think there are definitely ways in which we can improve our communication about beta (or alpha!) features, including attempting to label them appropriately and making sure the message is suitably clear. Your constructive feedback will help us do better in the future.
MZMcBride
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Here is one idea. A dashboard of top level Wikimedia projects with statuses, estimates, and a key to terms. Or does this exist? On Sep 20, 2014 3:37 AM, "Pine W" wiki.pine@gmail.com wrote:
Do we have a published guideline somewhere about MediaWiki quality standards for pre-alpha, alpha, beta, and production releases of elements like MediaViewer, VisualEditor, Flow, Winter, and HHVM?
Pine On Sep 20, 2014 12:14 AM, "Jon Work" jon.davies@wikimedia.org.uk wrote:
:} I am always impressed by those of you for whom English is not your native tongue. It can be very complicated to understand some of the shortcuts we use.
Sent from my iPad
On 20 Sep 2014, at 02:22, MZMcBride z@mzmcbride.com wrote:
Anders Wennersten wrote:
I also did soma very subjective test on response times and found the
new
feature to give 1-3 s quicker response, which is quite much (6s-5s, 7s-4s) and make a big difference in the user experience.
Woo! :D
Also after reflecting on my little harsh reaction on the deployment process, I wonder if it is not a language/communication issue
Being a non-native English speaking person I must admit I have no idea of the meaning "intrepid" means in "for intrepid beta testers". It seems for Guillaume it means "hey this is badly tested, but use if you have patience/courage" which I can accept as a message of a
testrelease
Also in my backgroud working in a company making internal deployment
of
software for 4000 internal users, I am used of making a huge
difference
in "ready for Alpha test" and "ready for Beta test", but perhaps my reference frame is inappropriate in this case, where perhaps a beta functionality means "Software for testing, not ready for release" and covering both my distinctions
So I apologize if I used too strong wordings and instead want to congratulate you on releasing a good function where you so speedily fixed the bug!
No worries. Thank you for taking the time to write up this message explaining. I think there are definitely ways in which we can improve
our
communication about beta (or alpha!) features, including attempting to label them appropriately and making sure the message is suitably clear. Your constructive feedback will help us do better in the future.
MZMcBride
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hello,
On Sat, Sep 20, 2014 at 9:32 PM, Rand McRanderson therandshow@gmail.com wrote:
Here is one idea. A dashboard of top level Wikimedia projects with statuses, estimates, and a key to terms. Or does this exist?
There is https://www.mediawiki.org/wiki/Wikimedia_Engineering/Dashboard
It doesn't have everything you mentioned, but we can build on it and improve it.
Thank you,
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Dashboard
This is exacly the sort of thing I had in mind. Although I do have a few suggestions.
1. The sizes of the rows are unwieldy. Maybe take the top X amount of characters from each status summary, instead of the full status summary, and make the links to the full status pages more prominent (alternatively, you could have a short summary have an expand link of some sort to expand to the full summary within this same page). Is there a template for this?
2. A column with a one or two word stage name like Pine described would be helpful, especially if you could sort on it. For sorting purposes, it would be cool to sort by the order of stages (although that is really just an icing on top sort of idea, probably could be done most easily by just having a number in front of the stage name).
The problem with just reading the statuses like these is that a brief statement about the fact that it is almost ready to deploy or something like that can get lost in a wall of text.
On 09/20/2014 04:17 PM, Guillaume Paumier wrote:
Hello,
On Sat, Sep 20, 2014 at 9:32 PM, Rand McRanderson therandshow@gmail.com wrote:
Here is one idea. A dashboard of top level Wikimedia projects with statuses, estimates, and a key to terms. Or does this exist?
There is https://www.mediawiki.org/wiki/Wikimedia_Engineering/Dashboard
It doesn't have everything you mentioned, but we can build on it and improve it.
Ori and all: this is really fantastic. Thank you. I'm seeing 2+ second speedups (on 6+s loads :/ ) on longish pages such as https://www.mediawiki.org/wiki/Project:Support_desk https://en.wikipedia.org/w/index.php?title=Main_Page&action=history
Rand, seconding some of your ideas: I would welcome a brief status table showing development-stage and one-line status for each activity, with a link to details.
For the detail pages: The status-history that most activities have is handy. A roadmap + timeline are great where they exist, but can fall out of date when updated manually. Perhaps this could be transcluded from an overall roadmap that is defined as the most up-to-date plan of record.
An overall priority list & 'what is needed next' would also help readers & contributors & testers understand what to prepare for and how to help. For instance with SUL finalization and other activities that involve a lot of coordination and communication and cleanup.
Sam
On Sat, Sep 20, 2014 at 4:48 PM, Rand McRanderson therandshow@gmail.com wrote:
Thank you,
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Dashboard
This is exacly the sort of thing I had in mind. Although I do have a few suggestions.
- The sizes of the rows are unwieldy. Maybe take the top X amount of
characters from each status summary, instead of the full status summary, and make the links to the full status pages more prominent (alternatively, you could have a short summary have an expand link of some sort to expand to the full summary within this same page). Is there a template for this?
- A column with a one or two word stage name like Pine described would be
helpful, especially if you could sort on it. For sorting purposes, it would be cool to sort by the order of stages (although that is really just an icing on top sort of idea, probably could be done most easily by just having a number in front of the stage name).
The problem with just reading the statuses like these is that a brief statement about the fact that it is almost ready to deploy or something like that can get lost in a wall of text.
On 09/20/2014 04:17 PM, Guillaume Paumier wrote:
Hello,
On Sat, Sep 20, 2014 at 9:32 PM, Rand McRanderson therandshow@gmail.com wrote:
Here is one idea. A dashboard of top level Wikimedia projects with statuses, estimates, and a key to terms. Or does this exist?
There is https://www.mediawiki.org/wiki/Wikimedia_Engineering/Dashboard
It doesn't have everything you mentioned, but we can build on it and improve it.
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Sun, Sep 21, 2014 at 4:05 PM, Samuel Klein meta.sj@gmail.com wrote:
An overall priority list & 'what is needed next' would also help readers & contributors & testers understand what to prepare for and how to help.
Yes. I agree that if we had been a touch more formal and disciplined about process, we would have engaged a broader subset of the community, to everyone's benefit. I take responsibility for that. Formal process management and regular bookkeeping are challenging for me, and I don't always know how to ask for help or share responsibilities. Your feedback spurs me to try and do better.
Samuel Klein, 22/09/2014 01:05:
Ori and all: this is really fantastic. Thank you. I'm seeing 2+ second speedups (on 6+s loads :/ ) on longish pages such as
And saving a null edit to https://meta.wikimedia.org/wiki/User:Cbrown1023/Logos went from 90+ seconds to ~30 for me I think? :p
Rand, seconding some of your ideas: I would welcome a brief status table showing development-stage and one-line status for each activity, with a link to details.
For the detail pages: The status-history that most activities have is handy. A roadmap + timeline are great where they exist, but can fall out of date when updated manually. Perhaps this could be transcluded from an overall roadmap that is defined as the most up-to-date plan of record.
An overall priority list & 'what is needed next' would also help readers & contributors & testers understand what to prepare for and how to help.
Also related: https://www.mediawiki.org/wiki/Thread:Talk:Quality_Assurance/new_tools_(moztrap%3F)
Nemo
For instance with SUL finalization and other activities that involve a lot of coordination and communication and cleanup.
Sadly, uploading images to Commons is as slow as ever, even with HHVM. :-( I often find that it takes a couple of minutes to upload a single photo, most of which is server-side delays rather than file upload time. I’m guessing that it’s something other than the PHP processor that’s causing this slow-down, though.
Thanks, Mike
On 22 Sep 2014, at 10:39, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Samuel Klein, 22/09/2014 01:05:
Ori and all: this is really fantastic. Thank you. I'm seeing 2+ second speedups (on 6+s loads :/ ) on longish pages such as
And saving a null edit to https://meta.wikimedia.org/wiki/User:Cbrown1023/Logos went from 90+ seconds to ~30 for me I think? :p
Rand, seconding some of your ideas: I would welcome a brief status table showing development-stage and one-line status for each activity, with a link to details.
For the detail pages: The status-history that most activities have is handy. A roadmap + timeline are great where they exist, but can fall out of date when updated manually. Perhaps this could be transcluded from an overall roadmap that is defined as the most up-to-date plan of record.
An overall priority list & 'what is needed next' would also help readers & contributors & testers understand what to prepare for and how to help.
Also related: https://www.mediawiki.org/wiki/Thread:Talk:Quality_Assurance/new_tools_(moztrap%3F)
Nemo
For instance with SUL finalization and other activities that involve a lot of coordination and communication and cleanup.
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Rand McRanderson, 20/09/2014 21:32:
Here is one idea. A dashboard of top level Wikimedia projects
https://www.mediawiki.org/wiki/Wikimedia_Engineering
with statuses, estimates, and a key to terms. Or does this exist?
No: https://www.mediawiki.org/wiki/Talk:Wikimedia_Engineering#Identifying_when_it.27s_too_late
Nemo
Le 20/09/2014 09:37, Pine W a écrit :
Do we have a published guideline somewhere about MediaWiki quality standards for pre-alpha, alpha, beta, and production releases of elements like MediaViewer, VisualEditor, Flow, Winter, and HHVM?
Pine
Hello,
The terms are pretty much standard in the industry. The different development stages are described at:
https://en.wikipedia.org/wiki/Software_release_life_cycle
Thanks, but I'm looking for something that is more specific to MediaWiki and that commits development teams to specific, standardized, and transparently measured quality metrics as products advance or regress in their path to production release.
Pine
Hoi. What is it that you want to achieve? What is the cost and what is the benefit? Reporting raises expectations and it solidifies development making it LESS agile and LESS responsive! The question therefore is so you have more information but what good does it do you, me us ? Thanks, GerardM
On 21 September 2014 09:51, Pine W wiki.pine@gmail.com wrote:
Thanks, but I'm looking for something that is more specific to MediaWiki and that commits development teams to specific, standardized, and transparently measured quality metrics as products advance or regress in their path to production release.
Pine _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Given longtime experience with problematic releases of MediaWiki features, I think that published quality standards that products must meet in order to become production releases could help to limit the number and seriousness of additional troubled launches. These standards would also reduce the ambiguity around terms like alpha and beta.
Pine
Hoi, The problem is not so much in expected standards, it is in realistic standards. The latest announcement of the improvement in speed was welcomed by someone stating "I do not give a fuck because my tool does not woirk with this crap".
There are two issues, tools break and are not part of the product and it has become the way people approach development. There is hardly any appreciation or respect for the work done.
I am not convinced at al by your proposall, actually I feel quite the contrary. I expect this will be counter productive. My feeling is that it enables to score points in the blame games . Thanks, GerardM
On 21 September 2014 10:24, Pine W wiki.pine@gmail.com wrote:
Given longtime experience with problematic releases of MediaWiki features, I think that published quality standards that products must meet in order to become production releases could help to limit the number and seriousness of additional troubled launches. These standards would also reduce the ambiguity around terms like alpha and beta.
Pine _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Just a few thoughts:
* I agree that the tone of the email that started this discussion about software quality standards was unnecessarily critical. Even in production releases, users may find occasional bugs.
* The intent of HHVM implementation and James' quick response to the problem report are nice to see.
* The perfect should not be the enemy of the good, especially for opt-in pre-production releases.
* Regarding standards for different release phases, I would need to think more about that but hope that someone will set up a proposed checklist on MediaWiki.org. We have some quality experts like Chris McMahon and their input would be helpful.
Pine
Pine, I believe your points are very valid and relevant
To know of the process WMF is using is a basic demand, in order for users to know what to expect and how to relate to releases.
To know what process is used is not the same as asking for more bureaucracy. Even a process description like "we let all programmers release in whatever status of quality they want" (if that would be true) is better then today, as it gives clarification
Then, but secondary to this demand of clarification, and also very important is that WMF is using a process on par with what is needed in this environment. And the process description could very well, (in order to allow for agile programming), only focus on criteria for releases, and skip how to get there
Anders
Pine W skrev 2014-09-21 10:24:
Given longtime experience with problematic releases of MediaWiki features, I think that published quality standards that products must meet in order to become production releases could help to limit the number and seriousness of additional troubled launches. These standards would also reduce the ambiguity around terms like alpha and beta.
Pine _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Fri, Sep 19, 2014 at 2:27 AM, James Alexander jalexander@wikimedia.org wrote:
Bug filed at: https://bugzilla.wikimedia.org/show_bug.cgi?id=71036
Yep! Good catch. Thanks James, Anders. I have a patch up at https://gerrit.wikimedia.org/r/161439.
wikimedia-l@lists.wikimedia.org