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

[S h i v]

On 9/22/07, Brandorr <brandorr at opensolaris.org> wrote:
> On 9/22/07, S h i v <shivakumar.gn at gmail.com> wrote:
>
> > But to articulate it into culture, somethings are(for me atleast) are
> > hazy/unclear. Too many things happening around Indiana. Probably it
> > will have some influence on how things are perceived by ppl at large.
> >
> > Many things are going right on the technology/project front.
> > But the things seem to be controlled to a considerable degree and
> > barriers to entry for external ppl/org needs further lowering.
>
> What do you want to do, that you have run into a barrier?
>

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.

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.

Barriers reduce as the disparity in the information seen and access
levels between an external person and a person within sun reduces.
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.

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.

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.