Mailing List Archive

Roadmaps and getting and keeping devs
These have been circulating in the open source Twitterspere today.
They struck me as apposite to discussions on these topics around
MediaWiki.

How to write a roadmap:

http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/

How to grow your contributor community (and how to decimate it):

http://www.codesimplicity.com/post/open-source-community-simplified/


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
On Samstag, 12. Februar 2011 at 17:55, David Gerard wrote:
> How to grow your contributor community (and how to decimate it):
>
> http://www.codesimplicity.com/post/open-source-community-simplified/
>

and imo, wikimedia fails at a lot of these points:

*Quote: "Respond to contributions immediately."
This is what I think bugs me the most. There are heaps of bugs which have had patches attached for month or years. For newcomers, who maybe spent a lot of time on these, it's just rude to neither commit them nor explain why they can't be committed immidiately.

*Create and document communication channels.
This has been talked about before, and maybe it did indeed get it little better.

Leo
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
For the last months I have been going through Bugzilla and what strikes me
is that we are not using it as efficiently as other communities do. In
particular, there is little follow up to reported problems (as Leo mentioned
as well). On the short term, I think we can have a bugathon to clean up the
buglist a little bit and re-energize some community members:

Have a bugathon where we label a lot of bugs as appropriate bugathon bugs
that need either:
a) test patch / update patch to recent svn version
a) confirmation / replication of new / unconfirmed bugs

We can provide a simple ready to go Wiki installation for people to use for
bug triaging and that way we can re-energize developers and clean up some of
the backlog of bugs.

Is this something that we should be doing?

On Sat, Feb 12, 2011 at 3:41 PM, Leo <diebuche@gmail.com> wrote:

>
> On Samstag, 12. Februar 2011 at 17:55, David Gerard wrote:
> > How to grow your contributor community (and how to decimate it):
> >
> > http://www.codesimplicity.com/post/open-source-community-simplified/
> >
>
> and imo, wikimedia fails at a lot of these points:
>
> *Quote: "Respond to contributions immediately."
> This is what I think bugs me the most. There are heaps of bugs which have
> had patches attached for month or years. For newcomers, who maybe spent a
> lot of time on these, it's just rude to neither commit them nor explain why
> they can't be committed immidiately.
>
> *Create and document communication channels.
> This has been talked about before, and maybe it did indeed get it little
> better.
>
> Leo
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
> Have a bugathon where we label a lot of bugs as appropriate bugathon bugs
> that need either:
> a) test patch / update patch to recent svn version
> a) confirmation / replication of new / unconfirmed bugs
>
> We can provide a simple ready to go Wiki installation for people to use for
> bug triaging and that way we can re-energize developers and clean up some of
> the backlog of bugs.
>
> Is this something that we should be doing?
>

This is something we do at hack-a-tons. I don't remember the number of
bugs smashed at the last one, but it was a decent number.

I believe the next hack-a-ton is in Berlin, soon. I'm not sure if they
have this planned. It's apparently GLAM focused (which excludes devs
like me), so I'd imagine not, unless the bugs targeted are GLAM
related.

- Ryan Lane

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
On Sat, Feb 12, 2011 at 1:11 PM, Ryan Lane <rlane32@gmail.com> wrote:
>> Have a bugathon where we label a lot of bugs as appropriate bugathon bugs
>> that need either:
>> a) test patch / update patch to recent svn version
>> a) confirmation / replication of new / unconfirmed bugs
>>
>> We can provide a simple ready to go Wiki installation for people to use for
>> bug triaging and that way we can re-energize developers and clean up some of
>> the backlog of bugs.
>>
>> Is this something that we should be doing?
>>
>
> This is something we do at hack-a-tons. I don't remember the number of
> bugs smashed at the last one, but it was a decent number.
>
> I believe the next hack-a-ton is in Berlin, soon. I'm not sure if they
> have this planned. It's apparently GLAM focused (which excludes devs
> like me), so I'd imagine not, unless the bugs targeted are GLAM
> related.
>
> - Ryan Lane

I'm curious: is there a way that non-technical people can help with
sprints like this? Documentation-building, maybe? Something else? I'm
interested in development sprints, bugathons etc that involve both
technical & non-technical people; I've been involved in a few and it's
pretty fun. But I don't know how many useful ways non-programmers &
non-developers can help.

-- phoebe

--
* I use this address for lists; send personal messages to phoebe.ayers
<at> gmail.com *

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
I think one way that non technical people can help is by trying to replicate bugs, if they follow the steps as described in the bugreport Do you get the same malfunction or not. That would be a great help as it weeds out invalid bugreports

Sent from my iPhone

On 2011-02-12, at 17:26, phoebe ayers <phoebe.wiki@gmail.com> wrote:

> On Sat, Feb 12, 2011 at 1:11 PM, Ryan Lane <rlane32@gmail.com> wrote:
>>> Have a bugathon where we label a lot of bugs as appropriate bugathon bugs
>>> that need either:
>>> a) test patch / update patch to recent svn version
>>> a) confirmation / replication of new / unconfirmed bugs
>>>
>>> We can provide a simple ready to go Wiki installation for people to use for
>>> bug triaging and that way we can re-energize developers and clean up some of
>>> the backlog of bugs.
>>>
>>> Is this something that we should be doing?
>>>
>>
>> This is something we do at hack-a-tons. I don't remember the number of
>> bugs smashed at the last one, but it was a decent number.
>>
>> I believe the next hack-a-ton is in Berlin, soon. I'm not sure if they
>> have this planned. It's apparently GLAM focused (which excludes devs
>> like me), so I'd imagine not, unless the bugs targeted are GLAM
>> related.
>>
>> - Ryan Lane
>
> I'm curious: is there a way that non-technical people can help with
> sprints like this? Documentation-building, maybe? Something else? I'm
> interested in development sprints, bugathons etc that involve both
> technical & non-technical people; I've been involved in a few and it's
> pretty fun. But I don't know how many useful ways non-programmers &
> non-developers can help.
>
> -- phoebe
>
> --
> * I use this address for lists; send personal messages to phoebe.ayers
> <at> gmail.com *
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
On Sat, Feb 12, 2011 at 9:41 PM, Leo <diebuche@gmail.com> wrote:
> *Quote: "Respond to contributions immediately."
> This is what I think bugs me the most. There are heaps of bugs which have had patches attached for month or years. For newcomers, who maybe spent a lot of time on these, it's just rude to neither commit them nor explain why they can't be committed immidiately.
>
This has gotten better lately, WMF created a bugmeister position and
the bugmeister tries to respond to most if not all bugs after being
reported. We should definitely keep up with this and try to at least
confirm every problem that is being reported.
The difficult part I think is responding to every patch. I don't
believe that we currently have the capacity to review those patches.
(In fact we barely have sufficient capacity to review the
contributions of our core developers!)

> *Create and document communication channels.
> This has been talked about before, and maybe it did indeed get it little better.
Being a volunteer, I believe that the staff<>volunteer communication
have greatly improved over the last couple months. I can't speak for
the developer<>non-technical community communication though.

We're obviously not there yet, but we are definitely improving.


Bryan

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In article <AANLkTi=nq2tOokvGMHRXbEgvr6fzXE1wzV9dBzdE4GFE@mail.gmail.com>,
Ryan Lane <rlane32@gmail.com> wrote:
> > Have a bugathon where we label a lot of bugs as appropriate bugathon bugs
> > that need either:
> > a) test patch / update patch to recent svn version
> > a) confirmation / replication of new / unconfirmed bugs
[...]
> > Is this something that we should be doing?
> This is something we do at hack-a-tons. I don't remember the number of
> bugs smashed at the last one, but it was a decent number.

> I believe the next hack-a-ton is in Berlin, soon.

Perhaps requiring people to travel to another country to participate in
this is part of the problem. I don't doubt that real-life meetings are
useful for Wikimedia Foundation employees and existing MW contributors,
but it doesn't do much to encourage new people to join in.

- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (NetBSD)

iEYEARECAAYFAk1XJGEACgkQIXd7fCuc5vL5UgCfQGe4tQa61xOev8fzBmOosmc1
VE0Anie2oDODr9mU+jXE+tkANJnfjpY6
=dJKA
-----END PGP SIGNATURE-----

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
>> I believe the next hack-a-ton is in Berlin, soon.
>
> Perhaps requiring people to travel to another country to participate in
> this is part of the problem.  I don't doubt that real-life meetings are
> useful for Wikimedia Foundation employees and existing MW contributors,
> but it doesn't do much to encourage new people to join in.
>

We also plan to have two US-based hack-a-ton's a year, and I believe
there is some form of one at Wikimania too. You don't always
necessarily need to travel to another country to get to one.

I don't disagree with your sentiment though. We should likely make
these events easier to attend online. We already put in the effort to
mark bugs before hand, and we all work on IRC while at the event, so I
don't see anything stopping online participation from happening. The
hack-a-tons usually don't have presentations, so that part isn't much
of an issue. We can likely stream out anything that needs to be, if it
comes up.

I believe that in-person events are key for people to get to know one
another, though. Maybe not everyone feels that way, but I definitely
do. I've worked on MediaWiki for years, and I feel I know other
community members much better since I've been meeting them in person,
much more so than the years prior. The hack-a-tons may not be
effective at bringing in new people, but I feel they are very
effective at solidifying the current community that we have.

- Ryan Lane

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
Leo <diebuche@gmail.com> writes:

> *Quote: "Respond to contributions immediately."
> This is what I think bugs me the most. There are heaps of bugs which
> have had patches attached for month or years. For newcomers, who maybe
> spent a lot of time on these, it's just rude to neither commit them
> nor explain why they can't be committed immidiately.

This is one of the things I've been trying to do as the new Bugmeister.

Every day, about 20-30 bugs are created. Especially in those cases
where the bug reporter is not a MediaWiki developer or regular user of
Bugzilla, I try to make sure that they hear back from me, even if it is
just “Thanks for reporting this, I'll try to make sure someone looks at
it.”

But, to your specific complaint about patches submitted through
Bugzilla, I like Diederik's suggestion:

> Have a bugathon where we label a lot of bugs as appropriate bugathon bugs
> that need either:
> a) test patch / update patch to recent svn version
> a) confirmation / replication of new / unconfirmed bugs

In fact, although I've been focused on the 1.17 release, I've also been
thinking about the 1.18 release. This would be a great way to start
addressing the creeping normalcy[1] that people have experienced with
MediaWiki. I definitely want to have one or two of these bugathons
during the next release cycle. If there is enough interest, perhaps we
can plan something for Berlin.

The other thing that will help is making more releases more often. This
is one area that I want to use my new role within the community: until
now, no one has been expected to make sure MediaWiki releases are made
“early and often” and we were all happy enough to focus on writing new
code while making software relases someone else's responsibility.

More frequent releases communicate vitality to software developers.

[1] http://en.wikipedia.org/wiki/Creeping_normalcy

--
Mark A. Hershberger
Bugmeister
Wikimedia Foundation
mhershberger@wikimedia.org
717.271.1084

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
2011/2/13 Bryan Tong Minh <bryan.tongminh@gmail.com>:
> This has gotten better lately, WMF created a bugmeister position and
> the bugmeister tries to respond to most if not all bugs after being
> reported. We should definitely keep up with this and try to at least
> confirm every problem that is being reported.
> The difficult part I think is responding to every patch. I don't
> believe that we currently have the capacity to review those patches.
> (In fact we barely have sufficient capacity to review the
> contributions of our core developers!)
>
I've also read one of the articles linked in the OP, and it got me
thinking about the fact that we're not only bad at responding to bug
reports (although bugmeister efforts are focused on that now), but
also at responding to commits. In the preparations for the 1.17
release I've seen lots of commits that were several months old and
only got reviewed because we decided to work on a release. Ideally,
every commit would be reviewed within a few days of being committed,
so the committer can still reasonably be expected to fix any issues
with it. Not letting review get too far behind HEAD is also important
for doing continuous integration, something I'm really gonna push for
now that I'm closely involved with the saga around deploying a new
version with about 15,000 new revisions.

Getting things reviewed fast ought to be doable if we set up some kind
of schedule where, say, 7 reviewers are each responsible for one day
of the week (or 5 reviewers for 4 36-hour chunks and one 24-hour
chunk, or take turns every 100 revisions, or ...) and reassign some of
their revisions to others where specific expertise is needed. This is
basically what we've been doing with the last 1.17 review sprint: Mark
Hershberger divided up the review queue between 4 or 5 people using
tags in CodeReview, and we would each go through our queue, review
what we could, and reassign the rest.

Bugzilla patches are another matter, yes, but I think making sure
patches get reviewed can be a Bugmeister task. We get relatively few
patches through Bugzilla these days anyway.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
On 13/02/11 11:54, Roan Kattouw wrote:
> Bugzilla patches are another matter, yes, but I think making sure
> patches get reviewed can be a Bugmeister task. We get relatively few
> patches through Bugzilla these days anyway.

Maybe once 1.17 is released, we should focus on the bugzilla patch queue
and get it solved. Would probably keep us busy until June.

Do we have any hack-a-ton planned? I can probably take a whole week
"day-offs" to participate and solve them.

--
Ashar Voultoiz


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Roadmaps and getting and keeping devs [ In reply to ]
Maybe we can make the bugathon part of the Berlin hackaton?

On Sun, Feb 13, 2011 at 4:03 PM, Ashar Voultoiz <hashar+wmf@free.fr> wrote:

> On 13/02/11 11:54, Roan Kattouw wrote:
> > Bugzilla patches are another matter, yes, but I think making sure
> > patches get reviewed can be a Bugmeister task. We get relatively few
> > patches through Bugzilla these days anyway.
>
> Maybe once 1.17 is released, we should focus on the bugzilla patch queue
> and get it solved. Would probably keep us busy until June.
>
> Do we have any hack-a-ton planned? I can probably take a whole week
> "day-offs" to participate and solve them.
>
> --
> Ashar Voultoiz
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
<a href="http://about.me/diederik">Check out my about.me profile!</a>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l