On Wed, 2013-01-16 at 16:34 -0800, Quim Gil wrote:
Some examples to illustrate.
Week 2: fresh bugs (Andre)
I don't think Andre will have problems finding tasks for this. But
again, if the top priority, WMF lead projects are well covered then we
can help and involve others e.g.
On 01/25/2013 03:27 AM, Andre Klapper wrote:
On Wed, 2013-01-16 at 16:34 -0800, Quim Gil wrote:
Some examples to illustrate.
Week 2: fresh bugs (Andre)
I don't think Andre will have problems finding tasks for this. But
again, if the top priority, WMF lead projects are well covered then we
On Wed, Jan 23, 2013 at 10:56 PM, Quim Gil q...@wikimedia.org wrote:
https://www.mediawiki.org/**wiki/QA/Weekly_goalshttps://www.mediawiki.org/wiki/QA/Weekly_goals
The first two events have the same date, Jan 28. Is that on purpose?
Željko
___
On 01/24/2013 02:10 AM, Željko Filipin wrote:
On Wed, Jan 23, 2013 at 10:56 PM, Quim Gil q...@wikimedia.org wrote:
https://www.mediawiki.org/**wiki/QA/Weekly_goalshttps://www.mediawiki.org/wiki/QA/Weekly_goals
The first two events have the same date, Jan 28. Is that on purpose?
No, but
We in QA discussed some possibilities for the browser test automation
community activities, and we suggest that the first couple of community
events be educational. In particular, we think it would be beneficial to
start with some introductory topics to be presented as a hangout+IRC
Thanks Chris Zeljko. We have two more weeks booked now:
https://www.mediawiki.org/wiki/QA/Weekly_goals
On 01/24/2013 09:30 AM, Chris McMahon wrote:
We in QA discussed some possibilities for the browser test automation
community activities, and we suggest that the first couple of community
* how to read, understand and analyze results in the Jenkins system we
have
for browser automation
A good proposal, booked for the week starting on Mar 11. Please help
defining what could be the practice, the actual contribution made by
participants at the end of the week.
It's right
On 01/24/2013 10:52 AM, Chris McMahon wrote:
* how to read, understand and analyze results in the Jenkins system we
have
for browser automation
A good proposal, booked for the week starting on Mar 11. Please help
defining what could be the practice, the actual contribution made by
This proposal got a basic agreement and is being implemented at
https://www.mediawiki.org/wiki/QA/Weekly_goals
A rough start is expected in the first iteration of the four areas but
we hope to have improvements every week.
Get involved!
Development teams: your proposals for testing bug
On Thu, 2013-01-17 at 16:37 -0800, Quim Gil wrote:
You are already planning a bug day around what I called Rotten bugs (are
you ok with the name?) :) It doesn't need to be the Big Bug Day. We
can start agreeing the goals... tomorrow? Then work on whatever
preparations and outreach are
On 01/18/2013 06:37 AM, Andre Klapper wrote:
On Thu, 2013-01-17 at 16:37 -0800, Quim Gil wrote:
You are already planning a bug day around what I called Rotten bugs (are
you ok with the name?) :) It doesn't need to be the Big Bug Day. We
can start agreeing the goals... tomorrow? Then work on
On Wed, Jan 16, 2013 at 3:25 PM, Quim Gil q...@wikimedia.org wrote:
All the better if there is certain correlation between testing and bugs
activities, but no problem if there is none.
I'm glad you mentioned this, it's something I'd like to bring up with
Andre and Valerie. Note that much of
On 01/17/2013 09:54 AM, Chris McMahon wrote:
How would this affect the notion of Groups?
http://www.mediawiki.org/wiki/Groups/Proposals
In a positive way. ;)
If after every week sprint a group gets one contributor more, then the
chances of having a better next sprint will increase.
I support this. It would give me time to follow up with assignees after a
bug day before the next bug day.
On Thu, Jan 17, 2013 at 12:07 PM, Quim Gil q...@wikimedia.org wrote:
On 01/17/2013 09:54 AM, Chris McMahon wrote:
How would this affect the notion of Groups?
Compared to the current situation, this wheel looks powerful and at the
same time relatively easy to set up. There will plenty of things to improve
and fine tune, but probably none of them will require to stop the wheel.
What do you think?
Our object here is to foster a community interested
On 01/17/2013 02:14 PM, Chris McMahon wrote:
Compared to the current situation, this wheel looks powerful and at the
same time relatively easy to set up. There will plenty of things to improve
and fine tune, but probably none of them will require to stop the wheel.
What do you think?
Our
On Thu, Jan 17, 2013 at 6:55 PM, Quim Gil q...@wikimedia.org wrote:
If we serve paella every week in a timely manner, people will come. If they
enjoyed it they will repeat another week, bringing more guests.
That is a good point. From what I've seen, these types of events also
tend to attract
On 01/17/2013 02:10 PM, Valerie Juarez wrote:
I support this. It would give me time to follow up with assignees after a
bug day before the next bug day.
Since the Features testing week seems to be moving to Jan 28, would you
like to step in and start next week?
You are already planning a
There are ongoing separate discussions about the best way to organize
testing sprints and bug days. The more we talk and the more we delay the
beginning of continuous activities the more I believe the solution is
common for both:
Smaller activities and more frequent. Each one of them less
Some examples to illustrate.
On 01/16/2013 02:25 PM, Quim Gil wrote:
Smaller activities and more frequent. Each one of them less ambitious
but more precise. Not requiring by default the involvement of developer
teams. Especially not requiring the involvement of WMF dev teams.
...
Imagine
20 matches
Mail list logo
