Weekly Meeting Notes, 10 June 2014

Weekly Webplatform.org Meeting,  3 June 2013


Chair: Eliot Graf (eliot)

Scribe: Amelia Bellamy-Royds (AmeliaBR)

Attending (On the teleconference and IRC):

Eliot Graf (eliot),

Jen Simmons (jensimmons),

Julee Burdekin (julee),

Renoir Boulanger (renoirb),
Vanessa Metonini (vanessametonini),

Amelia Bellamy-Royds (AmeliaBR)


 TOPIC: Onboarding of new members

<eliot>
http://lists.w3.org/Archives/Public/public-webplatform/2014Jun/0021.html

eliot: Julee's wrote up a nice outline of how to make sure new members are
welcome and have the resources to keep going

julee: the one thing I didn't inclued that might be worth doing is to keep
a list of new people for following-up

AmeliaBR: it would only work if it is actually up-to-date and we follow up.

eliot: would the purpose be to follow up after 30/60 days?

julee: So we could keep track.  We might postpone this until we have a
proper community drive.  Possibly in the early fall, when people are coming
back from vacation.

Eliot: Should we follow up (the original email) with a request for
assigning people to different action items on the list?

Julee: I can follow up this email, if everyone's fine with it, with a
suggestion that when we start the next community drive we set up a
checklist to make sure we're doing this for each new member

AmeliaBR: Clear responsibilities are important so that something actually
happens

vanessametonini: When I signed up, I wasn't really sure how to introduce
myself or how to get involved; I did not want to bother people

AmeliaBR: I'm not sure if we can change the automatic email sign-up email
to encourage people to introduce themselves

<eliot> renoirb: do we automaticaaly send mail to new members when they
sign up? Who owns that coontent? We can change it, right?

venessametonini: it might not be a good idea to have a new introduction
email from a new member every day, people don't want to spam the list if
they don't know it's welcome

<@renoirb> eliot, no we dont. We will have to build something.

AmeliaBR: current automatic welcome email is not very informative

* renoirb is working on a particular SSO feature that'll sign you in
automatically if you already authenticated.

ACTION: julee: send out follow-up email

<@renoirb> and for its development, i'm also working on command line API
calls to do maintenance.

ACTION venessametonini: will reply to julee's email with her perspective

<vanessametonini> yep

 NEW TOPIC: Following up on Issues and To-Do lists

julee: When we originally set up bug genie, the idea was that we would
regularly triage the bug reports and address them. but with other projects
going on, we're not really following-up. I think we need, maybe shepazu and
renoirb, integrating checking the infrastructure bug reports as part of
their other infrastructure work; and then the rest of us need to have a
schedule of dealing with content bugs

eliot: and have regular bug-bashing sessions

julee: Yes.  The bug reports break down into issues that require actual
pull requests on the infrastructure code, versus content issues, and we
need to separate triage groups to address them. I think this hasn't worked
before because the bug system hasn't been really integrated into any of our
special projects. We need regular meetings to address issues.

<@renoirb> i will join [the teleconference]

eliot: what kind of time do you think would be required?

julee:  ongoing 1hr/week, but more at first

renoirb: I deal with the infrastructure bugs ongoing.  But many of the bug
reports deal with stability or speed, and so can't be addressed until we
fix the more fundamental structural issues: SSO, updating mediawiki.  Once
those are addressed, most of the infrastructure bugs will be solved.

julee: but then there are the other types of bugs, relating to content or
templates

renoirb: once mediawiki is updated, there won't be as many problems with
templates

julee: Of course.  But even as the system is running, there will be regular
reporting of bugs.  We need a way to assign, on a regular basis, people's
time to keeping track of what bugs have been reported and dealing with
them. We need to decide how much of people's time is going to be devoted to
fixing bugs versus new projects.

<@renoirb> This http://docs.mroftalpbew.org/wiki is an upgraded version of
media wiki, also using SSO.

renoirb: As the full-time person, I talk daily with shepazu about
priorities, but once you're in coding mode working on one thing it's hard
to have to also switch to other things. I've got examples (link above)
about new mediawiki, but it's not yet ready to go,

eliot: we recognize that's all high priority work.  But separate from that,
we've lost track of any bug-tracking system, so that we can identify new
priorities as they come in.

julee: One thing, if renoirb expects that most of the bugs will be fixed
with this new system, we would really need to put off the triage until
after that is up, and then we could tell what issues would be fixed.

eliot: when is that going to be?

renoirb: some of it is already rolled out.  The big part in a couple weeks.
SSO will be rolled out for mediawiki and annotations.  At the same time,
I'll update both systems.

julee: Maybe we can target the second week of July for the full issue
triage, assuming renoirb's work goes as scheduled?

<eliot> BTW, issues are tracked at http://project.webplatform.org/

eliot: But we (eliot, julee, anyone else) can get started reviewing the
content bugs

julee: because none of renoirb's work will affect that?

renoirb: no, this is infrastructure

julee: Okay, so the plan would be to figure out priorities, start going
through the list and fixing what can be fixed immediately, then review
what's left

eliot: would this be a big chunk of time getting together?

julee: not for the first meeting, I think we need to strategize first

eliot: anyone else on the call able to help?

AmeliaBR: not for this month, maybe later

eliot: OK julee and I will set up an initial meeting and announce it on the
list

ACTION: on eliot and julee to organize new bug triage sessions

julee: we also need volunteers for who is willing to have bugs assigned to
them

jensimmons: Agreed.  This is important.  If bug system is not being kept
up-to-date, issues addressed, then new users won't bother using it, and
renoirb gets stuck as the only support option. There are also time
estimates for fixing issues; we need to figure out which ones can be
switched to shorter estimates. Our bug system is great, easy to use, we
need to convince people to use it!

 NEW TOPIC: QA Review

AmeliaBR: I will start sending out lists of articles to volunteers as a
link to a search page. There are 10 volunteers and 4000 articles, so this
will be rapid-fire. I will re-write the checklist to be very focused, IF
this THEN assign that state, so that people can go through a lot of
articles in a little time.

eliot: Make sure the emails ask for confirmation, so that if people can't
do it we can assign it to someone else. It's too bad we don't have a
central location to all meet up and do this together, like a DocSprint.

AmeliaBR: Agreed.  We can encourage people to keep IRC open and chat while
they're working, but beer and pizza would help...

(meeting adjourned)