[advocacy-discuss] Barriers to entry (was: The OpenSolaris "Attitude")

[Jim Grisanzio]

S h i v wrote:

> It is not just about me facing a particular barrier that wasnt
> possible to overcome. I elaborate this along with 2 points below.
> Also, before anyone starts explaining why it hasnt been done as yet
> even after being identified, I am aware of the reasons
> - limited resources v/s infinite improvement suggestions
> - Sometimes lack of will or the priorities of the decision makers
> being different
> 
> The end result is that these barriers exist as of today.
> 
> [1]
> I would place bugs db right on top. Spending 10minutes with
> launchpad.net and same amount of time with bugs.opensolaris.org makes
> it obvious.
> Bugs db is supposed to have been discussed at tools-discuss and a
> decision reached to replace it. But from what I gather this seems to
> have taken a low prio and nothing expected anytime soon.

I'd check in with Stephen on this:
http://blogs.sun.com/sch/
http://opensolaris.org/sc/src/website/spec/dts-requirements/d-dts-requirements.txt

> Finding spaces to contribute for a person who seeks is not difficult.
> It is about the ease of converting a user into a contributor. On the
> fora here, one needs to wade through the waters for (too) long before
> reaching a certain comfort level.
> 
> So, it is not really about me encountering a particular barrier that
> was not possible to cross.
> Whenever there has been a need to get inputs from sun engineers, I
> have without exception come across ppl who have gone way out of their
> way to help in getting the right information and providing whatever
> form of support was required.
> 
> But the point is many a times such mediation is required.


Ok, so is that a site organization issue or an issue of not enough 
infrastructure to enable participation? Or both! :)


> Barriers reduce as the disparity in the information seen and access
> levels between an external person and a person within sun reduces.

I agree. I've experienced this myself (especially since I've moved to 
Japan) and I tell people this internally all the time. There is still 
entirely too much information and conversation internal to Sun. Many 
times the issues are truly confidential and we have to live in two 
worlds (and that's difficult, by the way) but other times it's just old 
and familiar behavior. Sure, it's convenient to have hallway 
conversations and con-calls, but those meetings need to be put on open 
lists as much as possible.

> Note that having faster access for the day to day work is different.
> Also, I do not mean, free format or uncontrolled development process. 
> [2]
> This example is for the wiki infrastructure of opensolaris.org. I am
> aware that it is already identified as a replacement candidate. Till
> that is done whatever barriers it throws holds good.
> A person has worked through some parts ON/SFW/CCD, now he realizes
> there are things amiss on the project page or somethings have become
> dated due to the changes in the recent builds.
> Now, the only way to contribute is mail it to the list, the
> appropriate person(say project leader) responds, provide him the
> inputs via mail often in a form incompatible to the document where it
> should go.
> The project leader reviews it, acknowledges the correction, attributes
> the correction to the contributor.
> In the process,
> - the person contributing did not work directly with the right
> interfaces (project webpage - tonic language in this trivial example)
> - the project leader spent more time on these changes than it would
> have taken him to correct it by himself. This inspite of another
> person helping him out.

Agree. The site needs more flexibility. Point taken. I could suggest 
that project leads increase -- substantially -- the number of editors 
per project but then you run into the issue of having too many people 
editing pages and there is no tracking mechanism. I've experienced this 
myself, too.


> Instead, think of this workflow:
> 1. The person goes ahead and changes the wiki and updates it with a
> note to the page owner. (he does it on the spot when he has all the
> inputs ready)
> 2. The page visible to public is not updated till the changes are
> approved by the page owner.
> 3. Page owner does a review and approves it. If there are any changes
> required, just goes ahead and does it. For major review comments, get
> backs to the initial contributor. On approval the contributor gets a
> notification. Maybe makes him come back once again and spend more time
> on some of these areas and become a more meaningful/substantial
> contributor.

Good ideas here. I'm not aware of the state of the specifications for 
the site, but I now there's a project open for it: 
http://www.opensolaris.org/os/project/website/

> regards
> Shiv
> 
> ----------------------------------------
> Some more observations about bugs db that should be of no interest on
> advocacy-discuss.
> Most & many more have probably been discussed on tools-discuss since a
> post said decision to replace b.o.o was reached. But I wasn't able to
> find the original thread. Nothing much seen in that direction
> subsequently.
> 1. The interface itself is severely constrained.
> 2. All the fields of a bug are read only. (this is probably an easy
> point of entry for a user to turn into contributor)
> 3. A person cannot assign a bug to himself. Has no way of knowing who
> else is working on the same bug. No means to collaborate and leverage
> on other ppl's findings.
> 4. Cannot update the bug's fields with any of his findings.
> 5. Cannot track the bugs (ex:cant even find the bugs I raise!)
> 6. I cannot take a dump of the db
> 7. There are references to sun internal shares for further symptoms
> even for recent bugs. This probably is more to do with limitations
> arising out of (1) than unwillingness of people to put it in an open
> access location.

Jim
-- 
http://blogs.sun.com/jimgris