[Freeipa-devel] Community action plan

Wed Jun 17 23:43:40 UTC 2009

On Wed, Jun 10, 2009 at 10:07:43AM -0400, Dmitri Pal wrote:
> Hi Karsten,
>
> I am glad that we finally got someone who will help us to evolve into a  
> more open community.

And thanks for taking this as an open discussion.

(I've obviously got to funnel anything with PATCH in the subject from
this list to a sub-folder, I keep losing the topics I am most
interested in; sorry for the delay in response.)

> But I want to talk about two main problems:
> a) Technical problems
> b) Procedural problems
>
> The technical problems are related to CLI and its signing. I do not see  
> big issue with following your suggestions about CLI and moving to Fedora  
> infrastructure.
>
> I personally do not have a strong opinion about it. I just know,  
> however, that freeIPA was launched outside of Fedora on purpose.
> One of the reasons is to avoid affiliation with a specific distribution  
> and have a cross distribution community. We have not accomplished this  
> so I am open to trying a different approach but I would liek to hear  
> opinion of other developers on the matter.

The most visible part of FreeIPA associated with Fedora is the code
repository on fedorahosted.org.  Getting hosting from a Linux distro
is not unusual for a codebase, and there are a lot of packages in
Fedora, Debian, OpenSUSE, Mandriva, and so on where the canonical
project is hosted by one of those communities.  The FreeIPA branding
is strong enough to stand alone.  This is worth keeping an eye on, but
I don't think I'm too worried about that.

> We can also improve the wiki and access to it. I do not see a big  
> problem there either.

For increasing the potential for participation, that will help a lot.

> With the documentation there are two parts - there is a development  
> documentation and user documentation. The user documentation written by  
> one doc person is the aggregated information from the development  
> documentation plus this doc person's own research and experiments.

Right, I understand that model.  The same Content Services team is now
working in the Fedora community on pre-RHEL content, and while most of
their work is still DocBook, they are learning how to utilize
community work done via the wiki.

So, there are some pathways FreeIPA can follow where Fedora has set or
is setting a way forward, which won't interfere with the branding and
should add to the experience for new contributors and users in general.

> If we get a better quality of the original developer written
> document and information we will solve biggest part of the problem
> so I would start there.

I see that, let's talk about that.  Mozilla, for example, gained a lot
of documentation from their own developers by making a wiki that was
structured for them to document in to.  The same developers who knew
how but wouldn't check out and edit DocBook XML would edit a wiki
page.

The fact that we can snapshot that wiki in to DocBook is a good thing;
translation, upload in to a stand-alone hosted project for
collaboration (as we do with the other Linux content), etc.

I keep driving back to the wiki here because it's an easy solution
that could solve some of these developer documentation issues in ways
that grow participation.

> But the biggest problem is that we are running the project "semi-open".  
> We have IRC, email list and wiki. All possible information is exposed  
> there but it still not enough. And I would say that it is my fault.  I  
> see several issues with me and with the team here:
> a) I come from the corporate culture. I know how to run the project  
> efficiently if the development team is well defined and focused. I do  
> not know how to run projects in the open ended community. And we do not  
> have one so until no one from outside Red Hat gets involved I am running  
> the project as I see most efficient. This is chicken and egg problem. I  
> realize that while the project is run this way we might hardly get any  
> contributors but we will move on and operate as a well oiled mechanism.  
> Once we get someone involved we would have to adapt and adjust, but we  
> will not attract anybody until we change the way the project is run.

This is true, and a very good self-analysis.

I won't fool you; it does take change that has to include the team
leaders.  There are some practices that help, though.  The basic idea
is to i) make all information open and public unless there is a clear
distinction that it is confidential/private; ii) put all that
information in open and public locations.

So, even if all you have are 1/2 of the developer docs and 1/3 of the
roadmap written down somewhere, just moving all that to an open and
public location is a good idea.  Exposing everything helps _others_
write up to-do lists and start plucking the low and ripe fruit.

> b) There is no culture of writing good designs or capturing information  
> one got in a research of the code. "Go read the code" paradigm IMO is  
> the key issue. But trying to change the attitude is like boiling the  
> ocean. We can still work hard on keeping the designs up to date and  
> pages updated. This would be a full time job. I do not have cycles to do  
> it. Unfortunately developers do not have cycles to maintain the design  
> pages too. I am open to suggestions here since I think that sufficient  
> developer documentation is crucial for community involvement and quality  
> of the software. I do not think that jumping around IRC logs, mail  
> threads and wiki pages is efficient.  I doubt that anyone new would ever  
> go for such quest (until he is highly motivated for whatever reason).  
> There should be one place where any new person can get a good jumpstart  
> with the project including history of decision making, current status of  
> things and future direction. But who will do this? Again chicken and egg  
> problem: why would I spend cycles on this if nobody is reading; nobody  
> will read until it is sufficient.

Yes, and part of the hard decision that we have to make at Red Hat is
to lay the egg, early and often.  This is really the responsibility of
the core developers of a project, to get developer docs far enough
that others can actually assist; it's a problem I'm sure you know that
exists far beyond Red Hat.

The kind of thing we might find right away is a community person
interested in wrangling the documentation.  With everyone following a
page of naming rules and category conventions[1], we can create some
structure and stubs that developers can fill out via the wiki in much
shorter bursts than $other_methods.  One thing I can do is create that
structure to make it possible for a community docs wrangler to get
easy and early success.

>        So the bold changes should be:
> a) Solve technical problems
> b) Work with developers on improving the developer documentation
> c) Replace the manager

Thankfully, as humans our thinking can evolve.  Extinction isn't the
only answer. :)

- Karsten

[1] Like these:

  https://fedoraproject.org/wiki/Help:Wiki_structure

and some of these:

  https://fedoraproject.org/wiki/Help:Editing

In particular, this that makes conversion to DocBook XML easier:

  https://fedoraproject.org/wiki/Help:Editing#Marking_Technical_Terms

Heck, we can just borrow and adapt those. :)
-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090617/9cfc3eb4/attachment.sig>