Ideas on community organization and governance

[nachico]

Hi everyone,

it's been quite a long time since I wanted to write this post, but never found the time. I will try to keep it relatively short so that it is easier to engage in an open conversation.

As you have all probably realised, Zentyal is becoming increasingly popular as the project matures. However, the development team has remained the same and our resources are becoming increasingly stretched, like butter scraped over too much bread. As an example, there has been an extremely interesting thread on Zentyal Desktop, with a lot of bright ideas of all the things we could develop. However, the reality is that there are so many things the development team needs to do, that only a tiny fraction can be done for the next version. A poll on where our priority should be shows a strong demand on everything related with desktop integration, as well as disaster recovery, UPS support and IPv6 among others. It would take us years to cover the most demanded functionality. Unless...

... well, Zentyal is an open source project, and probably just by getting better organized we can make the most of the little time we all have available. On one hand, there is the current development team, with deep knowledge on the framework and with a company behind them sponsoring their time to continue the development and improvement of Zentyal. On the other hand, there are plenty of much needed, time-consuming tasks, that do not require so much knowledge on the framework, but that can sometimes drain most of the available time and energy from the core developers and bog down the progress of the project.

One of these tasks was, precisely, supporting this forum. Luckily, we have now the forum moderators, a team of seven members who heroically support other members and help keeping the forum alive. Zentyal developers are still participating actively in the forum, but thanks to the moderators, Zentyal can have both a forum AND a product alive and kicking. But there are many other small tasks that can easily be managed by other community members, freeing up time from the developers that can be better invested in improving Zentyal. I can see three clear examples:

• Bug squad: handling the stream of bugs reported by Zentyal users (removing duplicates, documenting the bug case, setting the priority, etc). You cannot imagine how much valuable time could be spared if a there could be some people ensuring that bug reports are filtered, well-documented and ordered by priority
• Documentation team: maintaining documentation for Zentyal, howtos, use cases, wiki, etc. We can only do the bare essential in documentation, but this is a task that can easily paralyse the whole development team for several weeks every year
• Localization team: Zentyal is partially translated to close to 40 languages, far from complete, however. One of them, Spanish, is directly maintained by the development team

Apart from that, there is the possibility to create specs/blueprints teams, that work together with the core developers to design user cases and write specifications, help with alpha and beta testing and identify usability issues. A good example of such a team could be Zentyal Desktop team, to help define what to develop in the desktop-server integration and help testing it.

I could continue summarizing my thoughts on how to articulate all this, but I would prefer getting some feedback at this point and learning whether this whole thing makes sense, whether there would be people interested in giving a hand, whether someone has already thought about it and where are the pitfalls that should be avoided.

Waiting for your comments.

[stuartiannaylor]

Firstly I think the idea of expanding the input of the community is an excellent idea. The ownership of branding rather than product (IP) has huge benefits as a low cost business model.
The answer is yes as socially, ethically and business wise it suits my philosophy.  As for organization and governance... erm that is a biggy.
I have the feeling that the poll on future direction showed much about the communities needs. Basically the community should vote and this vote like the American system should have an a SABDFL (electorial college) that can sometimes overide the common consensus for logistical or whatever reason.
I have been busy finding my feet and my main reason I support Zentyal is that it fits perfectly into my desired direction. AllLinux.co.uk is my own path and something I am about to kick start. I have a major bugbear that I work with community and social groups for the dissadvantaged. My bugbear is that we push them to learn commercial software that many can not afford legal copies.
Its a bizzare situation as perfectly good open source software is available and our users should not have to turn to crime just because the need to access essential infomation or documents online by the use of pirated software. Why we train people to use M$ in our context is a puzzling one to myself.

So the answer is yes for me either bug tracking, alpha testing or documentation. My question is what do I get? I ask that, as are there incentives that Zentyal could grant. Maybe concessions on input... I dunno but just a point.

Then going onto the desktop and I think we need another thread on this one or go back to the previous as it did cause a lot of heated debate.
Firstly XP EOL from the point of development is Now. It would be completely pointless to develop for XP as its short lifetime would struggle to provide R.O.I.
If you take that into account and have had the experience of trying to administer Vista/Win7 without active directory then like me you might say M$ is currently not on the agenda.
If you follow that thought path then it would seem sensible to provide an alternative which means some form of linux / bsd base.
Going from there I would say that Zentyal is based on Ubuntu LTS and so should the desktop.

Personally the desktop is a pain through qty, servers are great as they share resources to many and singular changes or fixes can populate to many users.
This is why I have my eyes set on the "thin client" and "private cloud" as means to provide centralised administration and cut costs.
Zarafa is a perfect example of a truly wonderful peice of software that is web based (private cloud) that replaces traditional desktop versions.
So for me there is the question of is there such a thing as the desktop and that is the browser not the new king.

I will leave it there but i would like input to where you think the desktop should go and for me its either lubuntu via thin client or purely web based. Maybe both but the traditional desktop maybe part of XP EOL.

Stuart   

[nachico]

Hi Stuart,

thanks for your reply. You covered several different topics in your post, and I will try to answer one by one.

Governance

I agree that the community + SABDFL is a good balance between open participation and effective operation. I think Ubuntu has a great basic governance rules that could be directly adapted for Zentyal. We should probably simplify the organization and processes, as Zentyal's community is way smaller than Ubuntu's, but I think the basic rules fit perfectly.

Contributors "compensation"

First, let me put this straight: Zentyal as a company does not have any interest in keeping a tight control on every aspect of the project. In fact, we consider ourselves as the main sponsors of the project, in the same way as Canonical sponsors Ubuntu, but we would like the community to have its own governance rules and responsibles, part of them staff at Zentyal, part of them not.

However, you are absolutely right in raising the issue: if someone gets a commitment with the community, what does he get? In my opinion, compensation should be in the form of status, power and influence. I think the forum moderators team can provide a good example. If someone becomes a FM, he automatically gets a higher, recognised status within the community, he gets administrator rights in the forum and in the community wiki, and he gets direct access to Zentyal staff in order to raise issues, ask questions or give an opinion. As they are the only non-staff members at this moment, they also have an important influence on community decisions.

Similarly to the FM team, members of other teams should get status, power and influence. Status through a recognised title, power through administration rights on some part of the community (bugtracker, wiki, pootle, etc), and influence by having a vote in community board meetings. There are many details to refine, but this could be roughly the idea.

Desktop roadmap

Desktop is a wide and complex environment, but we need to enter there, sooner than later. The scope we can cover varies a lot on how many people we can be pushing in that direction. If this thread is successful, and we can eventually form several teams that can help in different tasks, then we can prepare an ambitious roadmap that can cover several use cases, including thin clients Otherwise, we would start working on Kerberos integration and try to get it ready for 3.0. Then see what else we can do.

[christian]

• Bug squad: handling the stream of bugs reported by Zentyal users (removing duplicates, documenting the bug case, setting the priority, etc). You cannot imagine how much valuable time could be spared if a there could be some people ensuring that bug reports are filtered, well-documented and ordered by priority

Makes sense, except, from my standpoint, priority management. I can't imagine some one out of Zentyal team deciding about bug priority. Well, we may need to distinguish between what is urgent (on time line) compared to what is important (in term of impact) .

• Documentation team: maintaining documentation for Zentyal, howtos, use cases, wiki, etc. We can only do the bare essential in documentation, but this is a task that can easily paralyse the whole development team for several weeks every year

hehe... This is time consuming for anyone willing to put his hands in. HowTo, use cases and wiki can be handled by non-Zentyal members. Core documentation must remain in your hands. It really depends on code and version and must keep some consistency. Still community members could help at reviewing such documentation.

Apart from that, there is the possibility to create specs/blueprints teams, that work together with the core developers to design user cases and write specifications, help with alpha and beta testing and identify usability issues. A good example of such a team could be Zentyal Desktop team, to help define what to develop in the desktop-server integration and help testing it.

This one is an interesting one  but perhaps the one that will generate huge amount of fuzz and endless debate. Look at "Zentyal Desktop": there is already a lot of debate around products and implementation in many different directions    while target is still not very clear. I hardly imagine this could ever produce anything than inputs for Zentyal to make their own decision. Do not take it the wrong way. Providing such inputs is already not so bad  but very far from being anything close to specs...

[nachico]

Makes sense, except, from my standpoint, priority management. I can't imagine some one out of Zentyal team deciding about bug priority. Well, we may need to distinguish between what is urgent (on time line) compared to what is important (in term of impact) .

Good point. I guess there can be some kind of initial filtering that helps differentiate between critical/urgent bugs, and wishlists/minor bugs. But I agree, the final decision on priority should be taken by the developers themselves.

hehe... This is time consuming for anyone willing to put his hands in. HowTo, use cases and wiki can be handled by non-Zentyal members. Core documentation must remain in your hands. It really depends on code and version and must keep some consistency. Still community members could help at reviewing such documentation.

Agreed. It makes sense that the core team keeps the responsibility for maintaining the core documentation. But proofreading and complementary documentation can be provided by contributors.

This one is an interesting one  but perhaps the one that will generate huge amount of fuzz and endless debate. Look at "Zentyal Desktop": there is already a lot of debate around products and implementation in many different directions    while target is still not very clear. I hardly imagine this could ever produce anything than inputs for Zentyal to make their own decision. Do not take it the wrong way. Providing such inputs is already not so bad  but very far from being anything close to specs...

Well, that's the kind of situation where a SABDFL needs to use his authority

So, the way I see it, is that we need first a debate (mostly done), then a evaluation of available resources (on the way), then the setting of priorities and main use cases to cover (TODO, in open discussion if possible, by SABDFL if necessary) and finally the draft of detailed specifications that would help during development (by desktop team). Does it make sense?

[ichat]

finally - my favorite topic;).

i find this rather interessting...

Apart from that, there is the possibility to create specs/blueprints teams, that work together with the core developers to design user cases and write specifications, help with alpha and beta testing and identify usability issues. A good example of such a team could be Zentyal Desktop team, to help define what to develop in the desktop-server integration and help testing it.

This one is an interesting one   but perhaps the one that will generate huge amount of fuzz and endless debate. Look at "Zentyal Desktop": there is already a lot of debate around products and implementation in many different directions    while target is still not very clear. I hardly imagine this could ever produce anything than inputs for Zentyal to make their own decision. Do not take it the wrong way. Providing such inputs is already not so bad   but very far from being anything close to specs...

I would say that it might be nice to have a few community members that have lots of diferent views, one with technological advantage,  and another for buissness cases and yet another for ...<incert specialty> .

there will allways be a fuzz, its a matter of professionalism on how to deal with it...   for example earlier on in this debate people asked us what would happen with comunity governance if not the wrong features would be implemented for hoby users and the paying customers would stay in the cold.    and i allready mentioned than,  if we dont help ebox tech to make money they cant pay for the coders  and the train will stop... 

we the comunity are required to not only improve a product, but also safegard its existance.   

i would love to eventually start helping in the buggsquad (after i have familiarised myself more with the software, its a lot to learn you know ).  and im allready trying to be as active as i possibly can. and hope that eventually more people will do so too.

[stuartiannaylor]

The documentation already provided is good and what Ichat says is very true.

Alternative documentation on a more instructional rather than technical would be good for the less technical of the community.

I think I am going to have a bang at Naylor's guide to step by step guide from hardware to my normal setup.
I believe that there is no right way and its all shades of grey. Having used Zentyal for 2 years now I have my own way and favourites.

I am not saying my version is correct but a collective of documentation from various sources could be weeded for the best and maybe even parts from various could be built into some sort of wiki covering all aspects.

Also for alpha testing and bug squad details I am prepared to do my best. Time has been elusive recently but I plan to make time as I am passionate about the general way the development is going.

[nachico]

This is a very exciting conversation full of brilliant ideas that I would love to start putting into practice. Do you think it is time to stop chatting and start moving forward?

[ichat]

@nachico,  sorry mate still more talk and less to play with....

The documentation already provided is good and what Ichat says is very true.

Alternative documentation on a more instructional rather than technical would be good for the less technical of the community.

I think I am going to have a bang at Naylor's guide to step by step guide from hardware to my normal setup.
I believe that there is no right way and its all shades of grey. Having used Zentyal for 2 years now I have my own way and favourites.

I am not saying my version is correct but a collective of documentation from various sources could be weeded for the best and maybe even parts from various could be built into some sort of wiki covering all aspects.

a word of warning here is in place,  sharing information with other people is allways a good thing telling them your choices (and preferably why you choose this),  might help them understand more about the software.

BUT,  for community driven documentation to work,  coherence IS still required,  so unless we want to end up 10 diferent "howto setup  a 10 clients 1 server  zentyal as a gateway network from version 2.2"  just because  1 user preferes the use of  a  WAP with radius   an the other,   open wifi buth with  captive portal,  and yet another   wifi as a wan interface and  per client vpn connectons.   to give just 1 example  where it could get confusing.   at least some form or 'peer reviews' should be in place...   

so documentation-writers may sometimes just want to 'add' additional background information pertaining to other possible routes and functional design instead of re-writing the entire documentation..

this is not something i would ever want to enforce in any way,  but i do hope to see people  taking 'this' in to consideration everytime they need to deside whether to write new stuff or  update the old...

[christian]

I'm afraid this is not as simple... 
Users are often confused for different reasons:
- for those understanding what they want to achieve and why, what can be missing is a real "HowTo" matching their needs.
- some other have little idea of what needs to be achieved. Their read somewhere, via Google, that good practice is to deploy this or that. What they need before any HowTo is some documentation explaining some concepts and to make the right choice. From there, they may either deploy or most likely, select the right HowTo.

Second point is that Zentyal permits a lot of different designs. Having only one single "official" HowTo is a truncated view that may not fit all needs. furthermore, it can be somewhat misleading for people not understanding the very detail. I realized this when I worked on the proxy stuff: most people are deploying transparent proxy because the "official" Zentyal doc explains only this as the "perfect gateway" 

Thus I think we should keep:
- official documentation explaining all parameters and options, describing what is the impact (and today there is not enough technical explanation)
- as many HowTo as users want to share. But these need to be reviewed by people validating content.
- I feel that having some documents that are neither documentation or HowTo but cases description could help some users understanding where to go in term of design.

I know this is an endless journey but if we had only few documents explaining basics like "what to do and not do in term of network design", it may avoid people defining same network for both internal and external firewall network interfaces or having server bypassing firewall because of interfaces on each network.

[ichat]

chris i completely agree with you,  point i was trying to make however is this,  "if you are going to write a howto, first answer this 'not so easy' question,   is a newby user going to
A get even more confused by yet another howto on the same stuff. 
->  you better off  not writing a howto, but rather an explaination on your choices, preferences and the pro's and cons  from your choises - (background information rahter than a guide)

B get overpowered by the vast amount of weblinks, (cant find your exact howto in list as long as the beijing express)
-> you will only end up telling dozens of people  where  x version of  y howto is exactly.   (updating existing material rather than creating new one).

C or is it actually something new, or already asked for, (i.e: in the forums, feature requests etc)


maybe when we have better defined community governance and an 'organized' community documentation team, they could  create a clear and easy to follow guideline 'how to best write solid documentation and howto's",  but untill then  lets try to follow at least these basic principals as best we can.

[stuartiannaylor]

I think we need to bear in mind that part of the Zentyal funding is an administrator guide.
 
This is a technical document for the technical community and a commercial offering.
 
I do think specific "How Tos" in a non technical manner can provide more support to the non-technical elements of the community.
Many don't need to think of the reasons or implications but just need to know how. Web access email / business server with internet proxy for dummies for example should just be as guide to which elements to include and what tick boxes and settings need to be accomplished.
 
We can have a plethora of document submissions but the community should decide which ones are pushed and endorsed.
 
Its important to not cross over into commercial areas that might be the blood line of nessacary commercial support activities.

[christian]

Well, honestly, before looking for "HowTo" describing implementation, some should first look for "What" and "Why" otherwise some may end-up with solution just not fitting their needs (assuming they understand what their needs are, and I'm not joking here  )

Then once needs are clarified and solution understood, having cookbook or howto in order to deploy even not understanding how it works inside is fine.

[TropiRed]

Its important to not cross over into commercial areas that might be the blood line of nessacary commercial support activities.

By default, a How-To is generic in its approach, and specialisations comes after.

I have yet to see a How-To that manages to perform a business-worthy server installation (let alone, the different services around that server meant to be serviced) in a document less than 50 pages. Not to forget the flood of comments and replies  correcting the author for years to come, besides all the requests for solutions in particularly "tough cases".

No, if anything, the How-To will create business:
A) A good How-To inspire the reader to try something that could have gone past him otherwise.
B) A good How-To shows the reader (now client...) why all those hours actually are needed. It's not just Plug n' Play, we just make it look that way.
C) A good How-To can be a great tool to help a professional IT manager convince the company wallet why an investment in specialised configuration is needed.

Never fear the effect of good information. Fear the reaction of the uninformed.

And... I like where this thread is heading. Hakuna Matata

[stuartiannaylor]

My input is purely concern on how to gain funding for the Zentyal team and the bridge between community and Zentyal wealth.
 
This is only an idea but it is good to have standard methods and the Zentyal Admin guide does provide a commercial product that gains funding. This is why I believe we should try remain parallel to the "admin guide". In fact maybe howto's should reference the "admin guide"..."for further reference...page # zentyal admin guide".
 
I am not saying that the admin guide should stay static but it could represent the "Zentyal bible" where howto's are interpretations that reference the original source.
 
The sole reason for this is to create funding.