User talk:Mchua/Braindumps/Volunteers portal

A lot of this looks really good. I don't know how much of this will be cleanly implementable, but the introductory mentor idea sounds like it would be really helpful. I'm less sure of the proposed project setup, although having official authentication of projects does enforce quality control. Is the 6 week trial period just to convince people that your project is worthwhile? If so, why an entire 6 weeks? --Nikki 01:17, 28 July 2007 (EDT)

6 weeks is to convince people that your project is going to move forward and last and be completed and actively worked on more than it is to make sure the idea is worthwhile - it's easy to come up with a great idea but hard to follow through with it. And since the trial projects get all the same resources (hosting space, lists, whatever) as an active project (they're just not listed as active projects), it's not like we're denying them anything they need. Plus it means people have enough time to get something really spectacular up and running before their project is announced, so the new projects announcement has a high signal to noise ratio (SNR) and can point to already-working stuff... because new contributors are more likely to join a project that's actually got something going than one that's just got a vague idea, you know? Although I will concede 6 weeks is long. Maybe we can do 4. Mchua 12:00, 28 July 2007 (EDT)

Feedback

Introduction

So far so good. We should check in with someone from the main team in terms of summarizing, for consistency.

Sign-up

We need to get together a list of communities, which may or may not end up being painful. This will probably take a long time.

Personal contact/mentorship

• Create a place for current users to sign up for this
• Maybe a way for people to sign up for new users and receive reminders? (like, "it's been 1 week since User:XYZ has joined, have you checked up on them recently?")

Tiny Tasks

Implementing the tracking system may or may not be hard, depending on who does it. I don't know much about incorporating this sort of thing into the wiki (I've seen that it can be done, I'd love to learn how, but I'm on the 'before' end and not the 'after'). Also, this sounds organization heavy. Finding ongoing tasks to jump start the database will take a while, although it should go quickly if current wiki users are notified and encouraged to add in their tasks/projects.

Contribution Communities

A really fun part; building up a bunch of communities to the point of being able to take in newbies, train them some, and get them going. Should tie in closely with the problems under Sign-up.

Starting your own project

Shouldn't be that hard once we agree on a system (where new projects should go, for example) and find people to regularly review projects. Coding end might be a little tricky for me, but this has already been implemented with the SoCon setup.

Translation guide

This is a good idea. If people use it, this will be a great resource.

--Nikki 14:32, 3 August 2007 (EDT)

More feedback

Re (1), Introduction, yes, definitely. To write an email to friends saying "come help out", I should have simply been able to cut and paste a couple of paragraphs from the wiki, instead of having to write my own intro.

Re (2), Sign up, note that many people may start contributing before they sign up. My fuzzy impression is a large portion of Wikipedia contributions are still made anonymously. And even people who might eventually sign up, may initially start with small simple edits. And encounter the slippery slope of incremental commitment. We want to make that slope slippery and non-scary. Think how disastrous a "you must create an account and user page before you can edit" policy would be. Basically, we want to try to flatten anything which looks like it might possibly sometimes be a barrier to entry to someone.

Re (3), Mentoring and community followup, great ideas.

Re (4), tiny tasks, note that this can be much more difficult than it might seem. The overhead of maintaining such a the list, and of coordinating with potential contributors, can be quite large. I've tried, and failed, to create one of these. One might need a person for whom maintaining the list is "their thing".

Hmm, I wonder if one could create something low overhead which might be similar. Eg, might wp support people saying on their User page {{I wish|I knew whether wikipedia had a way of collecting text from many instances of a template into a single page}}, had have it show up in a common place. With datastamps and backlinks. Or something.

Re (6), starting projects... there are a couple of issues.

Our technical infrastructure has some gaps. We basically have the wiki and dew.laptop.org's git.

The wiki is easy to use, but seems to have some lacks as a version control system. Eg, it's not really set up to handle hierarchies of files, multi-file modifications, or access control. One could create a Project Foo/src/mumble.sh, but I don't know of a way to download the entire Project Foo file tree, and we can't have random people adding rm -rf * to mumble.sh.

Git itself has some limitations. Requires an ssh key. No native windows client. So windows folks would need to install cygwin to use it. This "if they aren't running linux, they won't be able to help anyway" assumption is ok for core source code, but obviously inappropriate for most content.

The way we are using git introduces additional limitations. Completely separate projects, with a tiny number of people with write permission, is inflexible and has a high barrier to entry. Which is what you want for existing projects where control are important. But is a poor match for incubating and growing new projects.

Basically, I think we need a svn repository in between the wiki and git. coderanger runs one, but it is a personal effort, and he goes back to school soon. And he hasn't been willing to create a "common" project, fearing mess.

So the model would be, the moment you need to do something which doesn't live on wiki, you get an svn account. Which let's you access all projects. And by default, you put things in a "common" project. With some sort of "old stuff" gets moved aside mechanism to avoid the cruft getting too deep.

So you can start something new by simply creating a new directory in the common project. Or, if you already understand the shape of the project, create a distinct project for it. As it becomes something you want more control over, you switch to 'no default write access', or move to git.

Examples of how our current model is failing include the June game jam code being scattered far and wide, and current difficulties in creating content bundles.

There are problems with this model. It works when the community is cohesive, but ours is less so. We are also under active attack, and it's not clear this approach can deal with that gracefully. Some others.

I was once told there is an RFP being drafted for a public repo. But I've heard no details.

Our current approach is working so poorly for content bundles (ie, you can upload .xol files to the wiki, but we don't have a usable story for anyone windows based to upload code for creating them) that this may force progress.

So that's a core infrastructure challenge.

Re (6) more generally, I like the concept of automated "freshness" maintenance. And providing guidelines. And mentoring. And supporting not-coders.

But note we need better support for non-coders working on code too. Much of a software project, art, translations, documentation, is done by folks who don't meet a "git is easy" test.

I suspect the "proposal, then project" distinction is too stark. Many projects seem to be more "groping in the dark, for something seen unclearly" in their initial phase. Which is part of why I don't like the "no common repo, create a separate one for each project" concept.

I'm not sure I buy the "instant project" concept. This came up in Creating an Activity, which currently suggests a very low thresholds for requesting git hosting and activity page creation. I would be unsurprised if this results in a great many "oh, I had an idea just now - now it's a project" unpursued false starts. Ah well, that's an argument for another time/place. My plan had been to suggest "start assembling content on your own user page" (which we really need to add the search index); "only create a wiki page when you have some content to put there"; discuss project ideas on the public ideas pages, and only spin of a project page when that makes sense by wikipedia refactoring standards; only create create an activity page, or a repo, when you have something to put there which will be of interest to others.

On the whole, I think the page has a lot of good and important ideas. :)

MitchellNCharity 16:17, 4 August 2007 (EDT)