Hi everyone!
What tools do you use for a small tasks in Google Summer of Code? I mean the tasks like "prepare the working environment", "learn gerrit", "write a blogpost", etc.? I thin that bugzilla is too heavy for this purpose.
Also can we use microblogging for reporting the current progress (in addition to posts in a blog one in 2 weeks )? I tried that once and it was very fun and efficient.
Cheers, ----- Yury Katkov, WikiVote
On 2013-05-10 3:52 AM, "Yury Katkov" katkov.juriy@gmail.com wrote:
Hi everyone!
What tools do you use for a small tasks in Google Summer of Code? I mean the tasks like "prepare the working environment", "learn gerrit", "write a blogpost", etc.? I thin that bugzilla is too heavy for this purpose.
Also can we use microblogging for reporting the current progress (in addition to posts in a blog one in 2 weeks )? I tried that once and it was very fun and efficient.
Cheers,
Yury Katkov, WikiVote _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I think traditionally we just told people to do things without using any "tool".
As for microblogging - by all means whatever works. There used to be a quite a few mw devs who actively used identica.
-bawolff
P.s. im not Quim, so my answers are unofficial and just my opinions, but I doubt we would have hard and fast rules on this sort of thing.
Le 10/05/13 08:51, Yury Katkov a écrit :
Hi everyone!
What tools do you use for a small tasks in Google Summer of Code? I mean the tasks like "prepare the working environment", "learn gerrit", "write a blogpost", etc.? I thin that bugzilla is too heavy for this purpose.
Also can we use microblogging for reporting the current progress (in addition to posts in a blog one in 2 weeks )? I tried that once and it was very fun and efficient.
A bunch of people at Wikimedia uses https://trello.com/ . It let you define pipelines and stick cards in them which you can then drag'n drop.
I use email to self for small tasks and Bugzilla with dependencies for the rest.
On 5/10/13 04:16 AM, Antoine Musso wrote:
A bunch of people at Wikimedia uses https://trello.com/ . It let you define pipelines and stick cards in them which you can then drag'n drop.
It allows you to do this collaboratively with other people, too. I recommend regular, short, synchronous checkins to go over your board(s) and move cards, along with the other people you're working with. (Like a daily standup, but can be at longer intervals, depending on your project.)
I find this hugely productive for all kinds of projects, and recommend Trello (and checkins) highly.
Pete
I guess someone has written in a management book something like
"Don't drive anybody into a project management tool that you are not using currently yourself." :)
On 05/09/2013 11:51 PM, Yury Katkov wrote:
What tools do you use for a small tasks in Google Summer of Code? I mean the tasks like "prepare the working environment", "learn gerrit", "write a blogpost", etc.? I thin that bugzilla is too heavy for this purpose.
The Bugzilla reports are there only for the usual Bugzilla workflow, hoping to get RESOLVED FIXED & VERIFIED by the end of the program.
What about the project wiki page? It's _just_ a project done by one student in about 4 months. It seems a sensible default: light and easy to learn, no extra registration required, transparent for anybody willing to watch and follow, free software, etc.
Also can we use microblogging for reporting the current progress (in addition to posts in a blog one in 2 weeks )? I tried that once and it was very fun and efficient.
"Fun and efficient" should be indeed the motto. For different people this means different ways of reporting, though.
The Wikimedia Engineering team has a discipline of monthly reporting and this is the minimum we are going to require to our GSoC / OPW interns, starting with the monthly report for June. Every participant will be asked to provide a URL to their monthly report, to be included in the Mentorship programs report that we publish at https://www.mediawiki.org/wiki/Mentorship_programs/status
That URL can point to wherever the student prefers: a section in the project page, a comment in the Bugzilla report, a post to the relevant mailing list, a blog post...
2013/5/10 Yury Katkov katkov.juriy@gmail.com:
Hi everyone!
What tools do you use for a small tasks in Google Summer of Code? I mean the tasks like "prepare the working environment", "learn gerrit", "write a blogpost", etc.? I thin that bugzilla is too heavy for this purpose.
Short answer: Google Docs, regular status meetings and a little bit of discipline should be enough.
Long answer:
I was a mentor in several projects. The most successful of them was in the last few months, and I mentored two students there. It's mostly done, and they are fixing the last bugs. They are actively studying, and together they had only about 10 hours a week.
How did it work? Very simply: We had weekly meetings. Each meeting began with the students doing a demo of what they achieved. Then we had a little discussion about where should the project go next and wrote a list of tasks for the next week in a shared Google doc. We were just adding more and more tasks to the end. We tried to stick to it and check that the tasks were completed in the beginning of the next meeting, and marking completed tasks as "done". And so on.
This way of management was inspired by the Agile management methodology, though it doesn't follow it precisely. The Agile principles that we tried to follow were: 1. As much as possible, letting the developers (the students) participate in the planning their own work and deciding what needs to be done. 2. Breaking the work into small and clearly defined tasks. This includes all work-related tasks: both actual coding, as well as stuff around it, such as "signing documents", "opening accounts", "learning Objective-C", "uploading to AppStore" etc. 3. Making a long-term plan, but being ready to change it along the way.
Trello was mentioned in one of the emails here. I didn't try it, but it may be good; It sounds like the kind of thing that was meant for this kind of task management. But honestly, if a Google doc works for you, don't work too hard to find something more complicated.
If the student you are mentoring has more than 5 hours a week, you'll probably want to do the meetings more frequently than once a week.
That's about it.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
On 2013-05-10 4:13 PM, "Amir E. Aharoni" amir.aharoni@mail.huji.ac.il wrote:
2013/5/10 Yury Katkov katkov.juriy@gmail.com:
Hi everyone!
What tools do you use for a small tasks in Google Summer of Code? I mean the tasks like "prepare the working environment", "learn gerrit",
"write a
blogpost", etc.? I thin that bugzilla is too heavy for this purpose.
Short answer: Google Docs, regular status meetings and a little bit of discipline should be enough.
Long answer:
I was a mentor in several projects. The most successful of them was in the last few months, and I mentored two students there. It's mostly done, and they are fixing the last bugs. They are actively studying, and together they had only about 10 hours a week.
How did it work? Very simply: We had weekly meetings. Each meeting began with the students doing a demo of what they achieved. Then we had a little discussion about where should the project go next and wrote a list of tasks for the next week in a shared Google doc. We were just adding more and more tasks to the end. We tried to stick to it and check that the tasks were completed in the beginning of the next meeting, and marking completed tasks as "done". And so on.
This way of management was inspired by the Agile management methodology, though it doesn't follow it precisely. The Agile principles that we tried to follow were:
- As much as possible, letting the developers (the students)
participate in the planning their own work and deciding what needs to be done. 2. Breaking the work into small and clearly defined tasks. This includes all work-related tasks: both actual coding, as well as stuff around it, such as "signing documents", "opening accounts", "learning Objective-C", "uploading to AppStore" etc. 3. Making a long-term plan, but being ready to change it along the way.
Trello was mentioned in one of the emails here. I didn't try it, but it may be good; It sounds like the kind of thing that was meant for this kind of task management. But honestly, if a Google doc works for you, don't work too hard to find something more complicated.
If the student you are mentoring has more than 5 hours a week, you'll probably want to do the meetings more frequently than once a week.
That's about it.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
One nice thing about wiki pages over google docs is that interested third parties can see what is going on (which I would consider a good thing)
-bawolff
On 05/10/2013 02:51 AM, Yury Katkov wrote:
Hi everyone!
What tools do you use for a small tasks in Google Summer of Code? I mean the tasks like "prepare the working environment", "learn gerrit", "write a blogpost", etc.? I thin that bugzilla is too heavy for this purpose.
Also can we use microblogging for reporting the current progress (in addition to posts in a blog one in 2 weeks )? I tried that once and it was very fun and efficient.
Cheers,
Yury Katkov, WikiVote
Unfortunately project management/tasktracking tools are just so specific to individuals' taste that I don't have a good recommendation (now that I'm no longer working at Fog Creek selling FogBugz).
Whatever you use, whether it's Remember The Milk or Trello or cronjobs or a wiki page using https://www.mediawiki.org/wiki/Wikimedia_Engineering/Project_documentation_h... templates or pump.io or some kind of IRC bot hooked up to three Roombas (one for the student, one for each mentor), it will work better if it suits the temperaments and tastes of everyone in your team. And if you choose to use something other than a wiki page, please do regularly paste some summaries onto a mediawiki.org status page; the project doc HOWTO gives you a bunch of useful functionality there.
The GSoC mentors' mailing list probably has opinions on this, I bet.
wikitech-l@lists.wikimedia.org