[Freeipa-devel] Community action plan

[Dmitri Pal]

Hi Karsten,

I am glad that we finally got someone who will help us to evolve into a 
more open community.
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.
We can also improve the wiki and access to it. I do not see a big 
problem there either.
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. 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.

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.
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.
        
So the bold changes should be:
a) Solve technical problems
b) Work with developers on improving the developer documentation
c) Replace the manager


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/