Jump to content

Big picture (Feb 2011): Difference between revisions

Revert spam
imported>Paulproteus
imported>Paulproteus
(Revert spam)
 
(20 intermediate revisions by 9 users not shown)
== Krzysztof's take on OpenHatch.org ==
 
OpenHatch, even toughthough it is a very young project, has proven to deliver what it [https://openhatch.org/about/ promises] (take me as a perfect example). Like any other young project, however, it gets some things right from the very beginning, while some areas need time to evolve (plus a lot of effort). Recent [http://irclogs.jackgrigg.com/irc.freenode.net/openhatch/2011-01-31#i_2523847 feedback from glyph] is a proof of that.
 
The following content is my attempt to identify ideas and concepts that should work toward achieving OpenHatch's mission. Although the observation is not based on data of any kind (be it raw numbers or simple feedback), it can still prove useful as a visionary playground for future releases.
==== Game mechanics ====
 
Game mechanics is the new hotness. In our case, they aremight thebe necessityusefull - we want new contributors to feel that they are making progress, be it by completing missions, being promoted to project maintainer or by closing bugs.
 
I personally think that ''missions'' is a good place to start leveraging game mechanics. We could introduce ''badges'' or ''titles'' system based on mission completeness and difficulty. But first, we need more missions which are build with game mechanics in mind.
* Goal: glyph wishes more projects had a clear "This is exactly what you do to submit a patch" page.
** Fix: We should make the presence of such a page part of the ranking of projects. We should make sure that we say it's okay if your page is hosted on your site. We should provide a reasonable template, and make it easy for people on OpenHatch discuss these pages on the forums. (I think we'll get some high-quality feedback from a community of people who hang out on the OpenHatch forums/mailing list just because they like to talk about what makes a good "How to submit a patch" page.)
 
=== Actionable: Help people join 'Task Forces' to make broad changes to projects ===
 
I'm imagining that there's a list of "groups" within the site. Anyone can form a group and invite people to it. Your group ''must'' name some achievable goal for its first month of existence; if it does not, the system forcefully disbands the group. (In order to stick around, your group has to provide a link to evidence that it achieved its goal. Someone from the forum or IRC has to mark the task force's goal as succeeded.) The group can only stay together for four months total; after that, its membership and achievements are frozen as a relic of the past.
 
Some groups I would like to see:
 
* The "License headers and copyright statements" task force
* The "Write a new OpenHatch training mission" task force
* The "Reach out to university students to teach them about open source" task force
 
I think it should only be possible to create a Task Force if you are a person who started a Task Force that succeeded in its first-month goal. (Maybe we can permit people who were ''part'' of a Task Force when it started to start them, too.)
* Actually, I think that anyone can ''create'' a task force, but it can't ''start'' its four-month existence until some other successful Task Force starter person agrees to join it.
** Then, if the Task Force succeeds, the person who starts it gets the "I can start Task Forces" status.
 
* We should provide ''some'' sort of in-group communication system for the Task Force, like a mailing list.
 
=== Rambling: Most projects don't want to put in the time to encourage participation; how can we help projects that do want new contributors highlight that? ===
 
When running the Penn workshop, I saw that there was a huge amount of interest from students who wanted to do something neat with open source.
 
== jesstess's take on the maintainer experience ==
 
As a project maintainer, what I want is
* a once-a-day-max digest e-mail and/or
* a section on my Openhatch homepage listing new people who have clicked the "I want to contribute" button for projects for which I consider myself a maintainer.
 
You could imagine the place where the "I want to help button" lives looking like:
 
For new contributors:<br />
[ I want to help ]<br />
 
For maintainers:<br />
Get notified when new people want to help [ checkbox ]<br />
 
* I like this. It would be not too hard to implement; if you have the project on your profile page then it shows the checkbox instead of the button. Also, if you have already clicked "I want to help" then don't show it (and maybe something else related to it e.g. "Started contributing? Add this project to your profile!") --[[User:Pythonian4000|Pythonian4000]] 21:53, 12 February 2011 (UTC)
 
with a checkbox on my profile for whether or not I get digest e-mails about new contributors (and maybe the list of projects you've checked the get notified box for, for easy toggling of whether or not you receive notifications). Mousing over the [ Get notified ] button explains what will happen and that you can configure settings on your profile page. You always have a "new contributors notification section" on your homepage containing people who've clicked the [ I want to help ] button for projects you've asked to be notified about. This would probably be a box with a max size, with a [ see all ] link taking you to the full page of contributors if the number exceeds the box size.
 
I have less clear a vision on how you'd clear out the new contributors section. There could be a [ clear all ] and individual clear buttons next to each entry, so you can keep track of people you've reached out to. There could be both a [ clear ] button and a [ contacted ] checkbox. If I were implementing this I wouldn't worry about the details for version 1.
 
* The [http://openhatch.org/+feeds/activity/ Recent Activity Atom feed] currently has people who click the "I want to help" button in it, so it would also be possible to generate Atom feeds for individual projects. --[[User:Pythonian4000|Pythonian4000]] 21:53, 12 February 2011 (UTC)
 
== Palhmbs's view / problems on/with OpenHatch.org ==
No. 1: Open Source involvement has to be both fun, and rewarding for new contributors/maintainers to stay interested.
 
=== Bug Trackers ===
I think it would make a huge improvement to the open source communities perception of Openhatch if we were able to add the Projects Bug Trackers quickly.
** This probably means that more than 1 person should be working on implementing adding Bug Tracker types.
** The new Bug Tracker GUI should go a long way to making adding a projects tracker as pain free as possible.
** Displaying the bug tracker info with a iframe / overlay is a great idea, but needs fleshing out, we should capture metrics - http://openhatch.org/bugs/issue247
** Making sure that the speed of the site and the space available on the site does not adverse affect the user experience. This involves monitoring the site effectively, and setting targets for expansion of OpenHatch as it gets more users and more projects (bug trackers).
 
=== Old issues in OpenHatch's Bug Tracker that seem to have been forgotten ===
There are a '''few''' very old bugs (under issue 100) that ought to have been closed or fixed, show our love for OpenHatch by getting these old issues sorted first.
 
=== Mentorship should be handled adequately ===
This is huge, new contributors usually want help quickly to keep motivated, unfortunately mentors have limited time!! So if your looking for a mentor, usually you need 1, 2 or even 3 in a particular coding language to be able to get that help.
** Also as a mentee, I'd find mentoring more rewarding if there both parties had more opportunity to do collaborating. (Pastebin just doesn't cut it usuall) - making mentee's and mentors aware of more collaborative tools to getting things resolved.
** If a big project already has development policies / guides in place then OpenHatch needs to be able to link to those and provide that information adequately.
** Mentors should not only state they are available, but also how many people they think they might be able to mentor.
** Mentors and mentees need to be encouraged to keep in touch with eachother.
 
PS. I've been involved with a site that concentrates solely on mentoring http://www.mentornet.net/ ...
** The No.1 problem I've noticed is in getting the right match up ( not all people match eachothers individual personalities )
** Keeping both parties interested in keeping up contact. Too often it's the mentee/mentors fault for not being proactive enough.
 
=== A Project Maintainers Build Helper ===
Let's also pro-actively get projects to simplify their build processes to break down the new contributor barrier.
 
=== Have a Openhatch Roadmap ===
** Set attainable targets, and have longer milestones (every 2 months)
** Group people's talent together ( UI , Bug Tracker, Missions, Outreach, Meetups ) - btw I like Asheesh's "Task Force" idea.
 
=== Describe different types of OSS involvement ===
Alot of projects I've noticed have problems finding specific types of contributors, some of them really, really need documentation helpers, but because in medium-sized projects nobody is interested in documentation, it gets missed.
Other projects really need bug triagers or translation specialists etc.
So - make it easier on Openhatch to allow projects to promote specific areas of these sort of bugs, or a specific tag on a bug.
 
/braindump
Anonymous user
Cookies help us deliver our services. By using our services, you agree to our use of cookies.