Meeting Notes, Was: Community Telcon Agenda, 29 July 2014

Telcon starting...

shepazu in the chair

<+jensimmons> who’s on the call?

[Edited later to answer:

shepazu, eliot, julee, AmeliaBR (scribing), jensimmons; renoirb joins
partway through]

* eliezerb is reading
First Topic: Translations

shepazu: There was email discussion, what should be done?

AmeliaBR:  There are a couple issues.  The translation system we've got is
just Mediawiki, not Semantic mediawiki.  Two issues: no way to
search/filter by language, and no translation of template content;
translations have to be made up just with Mediawiki formatting.

shepazu: do we need a clear instruction for new users?

julee:  There is some sort of material, and people are already doing this,
so we might as well encourage it.

* renoirb just joined shepazu

...There were a number of pages (sent in the email by AmeliaBR), but I
clarified which one page has the reference we should be sending people

...also, I usually search the email list to see if anyone else is working
on that language

shepazu:  I think we need one clear reply.  We had lots of people replying
with important facts, but not a consistent voice.

julee:  We need a standard onboarding email for translators just like for
new editors

shepazu:  I might try to find people who have been working on translators
to help figure out the important points

jensimmons:  I think we also need to make sure that there is one definitive
page, working from what we've got but also removing any conflicting pages,
so that we can just point people to that.

julee:  There are a couple of other pages that are important discussions
about what we *could* do or what we might do.  What should we do with
that?  Put it in the bug base?

jensimmons:  Not necessarily.  We just need to rewrite and make sure
everything is connected and clear.

AmeliaBR:  We need to at least clearly define that these pages are
discussions, and redirect to the definitive page about what is going on.

jensimmons: Oh if those pages are just theoretical discussions, maybe they
should be in Bug Genie.

shepazu: next step?

jensimmons:  Write it up in Bug Genie as a user story.  I can do that.
Next TOPIC: QASprint

AmeliaBR:  Status is still slow.  I need to send out nag emails.  Including
to you, shepazu.

shepazu:  I've got Dave Gash doing mine.  And also renoir's and eliezerb's,
because they're busy with Compatibility Tables templates.

julee: We love Dave Gash!

shepazu:  How many left to do?

AmeliaBR:  Hard to estimate, since the non-English pages throw off the
numbers.  About 1000.  Some people I haven't even heard from, others like
Rob, have been slow but steady making pages Ready to Use as they go through.

<+jensimmons> AmeliaBR: what’s the link to the status page (of what’s been
Q/Aed or not)?

<+AmeliaBR>
http://docs.webplatform.org/wiki/WPD:Projects/QASprints/2014-june  (final
numbers at bottom)

shepazu:  Is it essential that everything is reviewed?  I mean, so long as
pages say that they are *not* reviewed, that's okay.

AmeliaBR: that doesn't currently show up.  But we could change the CSS to
show a banner for unreviewed pages.

eliot:  Before we give up, we should take stock of what we are doing, and
whether we can finish this.

shepazu:  Can we at least rally the troops, find new volunteers who maybe
aren't asked to commit for so much.

AmeliaBR:  I can, today, send an email to my previous volunteers checking
to see who is still working.

...then, later this week, I'll go through what's left and break it into
short (20 article) blocks, and not assign them, just ask people to check
them out when they are ready to actually sit down and work on them.

shepazu:  That sound good, thank you.
NEXT TOPIC: Compatibility Tables

shepazu:  Quick update.  There was some delays with Eliezerb getting logged
into the test system, but he and renoirb have figured that out.  It should
be happening this week.
NEXT TOPIC.  Issue Tracker

jensimmons:  The main change we've been making is condensing the many
different projects into two, content and infrastructure.  We hope that a
user going to the bug tracker can now easily figure out which one to use.

...We've redefined infrastructure to mean anything regarding server,
website, log ons

shepazu: anything that's not content

jensimmons: exactly.  And for content, although some people will file bugs
about specific pages, the purpose is to round up all discussions about
major content issues that affect many pages

...Beyond bugs, we really hope the system will organize all the projects
and ideas we've been discussing on these calls and set up priorities.

...The way that it was set up, we couldn't use it to plan across different
projects, to set priorities e.g. for getting ready for a DocSprint.

...This will allow us to keep focus on the things that we have agreed are
priorities, not get distracted by new shiny things.

...We're using an Agile-like system.  We've simplified the number of
tickets; there were too many flavours, many of which were very similar.

...Now we've got "bug".  Which should be explanatory.  Things that are
"shipped", we thought they were done, but they're not working.

...Then there is "feature requests", which will not be directly used.  But
if people have ideas, that's where to put it, and then if the triage team
decides to go with it, it gets turned into a story ticket.

AmeliaBR:  And not just the triage team.  We could leave those tickets open
for discussion about whether or not a feature request is a good idea and
how to do it.

julee:  For clarity, the triage team's job is to decide if this is a real
issue, and if it is properly categorized.  If it is, it becomes a story,
and then the story becomes the place to discuss the idea.

AmeliaBR:  Ok.  That makes sense.

jensimmons:  A bit about the "story" idea.  I know when I first started
with Agile project management, it seemed unncessarily complicated, and I
just wanted to go back.  So please bare with us for a few months before we
reassess the system.

...This approach is really useful to organize the ideas, not just of what
we're doing, but of why we're doing it, and all the steps of the process
and the priorities.

...The way we've restructured Bug Genie, there are things called "Stories",
which are structured in "As a {type of user}, I can {do something}".  The
statement is what would the result be, if unicorns and fairies showed up
and magically made it happen.

...It's a false statement at the time you write it, but then when the story
is completed, it becomes true and we close it.

...But there's nothing here like "Install WordPress" or "Fix
templates".  Those are tasks, not stories.  Tasks are important, but every
Task, in this world, is associated with a story.  Once we decide on a
story, then next thing we do is write up the tasks that need to be done.

...But the nice thing about stories is that you don't *have* to think about
what needs to be done, you focus on what you want, and prioritize it, then
you think about the technology issues.

...Does that make sense?

shepazu:  I'm familiar with things similar to this, although I've never
heard it cast this way.  It seems useful,to separate out the functionality
from how we get to that functionality.

jensimmons:  Yes, we wanted to separate out the end goals, and our
priorities for those goals based on impact on end users, from how we reach
the end goals.

renoirb:  I have no problems.  This is what I would like to do.

julee:  Basically, it will be a combination of bug base issue tracking with
standard engineering project management.  One goal is to be able to create
reports about the project, what's happening, and the priorities, that any
user could go onto the system and explore.

...Another key part is a new home page, that is helpful both for users who
want to report a bug and people who want to see the project as a whole.

...We will need to customize some modules for Bug Genie to make this
happen, and perhaps create some new modules for specific views of the data.

...I've talked with renoirb a bit, but we need to discuss how to actually
update it?  Pull requests on github?

renoirb:  Most of what's installed has been there for a while.  It was
handcoded with no versioning controll against the original Bug Genie
code.  I need to figure out a diff against the source code, so that I can
update the source code and figure out what to compare.

julee:  Could we just take the current snapshot and put it on github or
somewhere, and then work from that.  I've already tried working with the
latest Bug Genie version, but it doesn't have the customizations.

renoirb:  I am working on trying to put everything into source control.  I
want to update to the latest Bug Genie, and not have our own version of
those files.

julee:  Most of the changes we want to make are in the user interface or
module files, not in the core.  Can we not work with what we've got, and
update the core Bug Genie files later?

renoirb:  That could happen.

julee:  Because this sounds like a lot of work for you, and you have other
priorities.  If you can just share the files with us, then we can try out
all the changes, and you can decide whether they need to wait until Bug
Genie is updated.  But the changes would all been in github.

renoirb:  Yeah, I see, but at some point I'm going to have to do a big diff
of all the files, and that's going to be a big mess

jensimmons: but where are the files now?

renoirb:  It's in github, but the live version has all sorts of things like
password which I can't just push to git.

julee:  Okay, I understand now.  So if we work with what is currently on
github, we can make the changes you want, and then you can go into the live
files and update?

renoirb:  Yes, that's just what I want.  I'll help show you how to make a
patch on github that I can use.

shepazu:  Okay, Julee you have a clear action, renoirb you can follow up
with them.

...Any other topics?

julee:  Maybe this is for next time.  I do want to talk about the
community, getting people re-engaged, especially in the fall as people are
coming back.  Can we work on a strategy in August to roll out in September?

shepazu:  I'll put it on agenda for next week.  Thanks everyone.




On 29 July 2014 10:36, Doug Schepers <schepers@w3.org> wrote:

> We'll have a Webplatform Docs community call today, 29 July 2014.
> The call will take place at 1700UTC (13:00 ET / 10:00 PT), on the regular
> phone line and IRC channel [2].
>
> Telcon Info:
>  Zakim Bridge: +1.617.761.6200
>    VOIP: sip:zakim@voip.w3.org
>  Conference code: 3627 ("DOCS")
>  IRC Channel: #webplatform
>
> Anyone can call in free of charge by using a SIP client [3]. The meeting
> minutes will be made public.
>
> Can I get a volunteer to scribe?
>
> Agenda:
> * QA Sprint
> * Issue tracker and TODOs
> * Translations
> * CompaTables templates
> * Review of open action items
> * Any other topics?
>
>
> [1] http://everytimezone.com/#2014-6-17,1700
> [2] http://docs.webplatform.org/wiki/WPD:Meetings
> [3] http://www.w3.org/2006/tools/wiki/Zakim-SIP
>
> Regards–
> –Doug
>
>
>
>
>
>
>