I’ve already wrote about this idea a while ago. In the meantime some people told me they really liked it, but I was also told that it needs more details. I’m writing this post to update the idea and afterwards I’m going to create a Blueprint, because someone asked for that. This is however not a finished version.(Yes Please don’t think I’ve got the powers to surpass the Ubuntu community and keep giving feedback. The reason I’m using this blog, instead of brainstorm, is that it’s more suitable for large posts in my eyes than the brainstorm comments section. The blog also reaches a large audience.
He liked the idea, but also had some concerns. The main concern was that it could splinter communication. Most teams communicate mainly on their IRC channel and with their mailists. If suddenly all new tasks would appear on a separate website, things could become very confusing for team members. They don’t know where to look. And discussions about applicants would take place at more than one place. You’d have the mailist, but also the wanted site.
This problem could be solved by letting the wanted website mail all new jobs and applications to the mailist of the team. A bot can place the reactions in the comment tree at the website.
Another part of his concern was that such a website could let it look like you can only have one job/task within the Ubuntu Community. However, there’s no rule telling you how many jobs/tasks you can have. If a wanted site would be created, it should be made very clear that there’s no limit. For example, calling the ‘items’ at the wanted site ‘jobs’ would probably make it sound to big. I think tasks would be better, but that’s something that should be defined by people that are experienced with things like this.
It should also be very clear what is allowed at the site and who can post. Some people would like to use it also for jobs outside the Ubuntu Community, e.g. a system manger for the server of the local football club, but I think it should be restricted for tasks within the Community. More items would cause too much noise making it harder to find the task you’ve always dreamed of doing. I think it would be the best to give each team its own category and create two types of tasks: dynamic(team leader, maintainer of package X) and static(bug triager, MOTU). These different types should be easily distinguishable. As authentication method the developers can use OpenID, since LP is an OpenID provider. I’m not sure if you can also request a list of teams the user is member of, but I’m asking it right now at #launchpad and will update this post when I’ve got the answer.
The biggest problem in my eyes is how to determine who is allowed to place items. Just the team administrators? Anyone? Or just the wanted site crew? The best option, according to me, would be to allow all team administrators to post ideas. But from what teams? There are loads of teams registered at Launchpad and not all of them have something to do with Ubuntu. And teams like Ubuntu Smokers don’t really need to place items. I think(Wow! I really think a lot!) that it would be the best to let the team administrators request access. When they’re approved an admin adds them to a list against which the results from the Launchpad teams query are checked.
At brainstorm someone also suggested to allow mentors to be assigned to tasks, which is a great idea according to me. However, are there enough volunteers who are willing to help newcomers?
A last question is which programming language should be used. Most Ubuntu websites seem to use Python and it would surely be a good idea to use it, since integration wit LP would be a lot easier. So I’d vote for Python, even though I’m not very familiar with the language.
Please post your feedback!
EDIT: I’ve created a Blueprint: Blueprint: “Ubuntu Wanted Site”