I apologise if I seemed to be a tad bit obnoxious (re: previous comment), but whilst I recognise that we can always implement new technical procedures (and I commend giacomo and davidep for providing practical and sensible ideas in relation to these update procedures), I have found (from previous experience of supporting other projects, both within commercial environments and within “public domain” based projects) that it is all very well to have good technical solutions, but unless there are well written documentation and procedures / polices for a given project, these technical solutions / projects can be severely let-down to do the lack of proper, well thought out documentation.
I do believe that without such polices and a lack of sensible and pragmatic documents, these projects / developments can loose a form of credibility, especially when said project is built upon the concept of open-source ideals, where there may not be a clear “managerial structure” or when some of the community diverges from the original project (note: I am not stating that NS particularly suffers from any of these problems).
Consider the issues that other open-source projects have had due to insufficient or poorly written documentation, also think about those projects that have been forked due to the above and other similar issues (a good example would be the problems surrounding a project like opnSense and pfSense, in which these two communities are still facing major backlashes from their opposite number / competitor).
Good point, we’re too technical sometime and overcommunicate is not a bad thing
How can we start such process? Which points are we missing or are not clear enough
Ok, I think that this deserves some proper thought and discussion, but my initial ideas would be in relation to a two step process.
First step, would be the issues surrounding producing good internal policy documents / procedures, which would describe sensible procedures in relation to update and release cycles (and other related issues).
The second step is in relation to a well written and concise administration / user guide, as I have stated in past comments, I have been toying around with the idea of producing a guide akin to a “for dummies” book / manual (which could provide further examples of NS usage within realistic environments).
I think that the above two ideas are good first-steps and should be examined in further detail.
Hi Mark,
Your points are great. Not my intention to criticise anyone , but I just chiped in my thoughts.
It is indeed needed to have a documentation (a clear and good documentation) and procedural aproach.
Also you have to take into account the resources needed to obtain that…
.
More people are needed or, burden further the people allready having other tasks.
Time to create and manage and update those procedures -> This can lead to the fact that documentation might stall the develop process or the time needed to finish a task or reach a milestone will increase.
Not to become more complicated than it needs to be (on some cases the procedures become so complex that they are useless)
Who will take charge to steer all of those
And I think that there are enough points to consider further.
@Ctek,
Thanks for your reply and feel free to critique my ideas (the more views that I receive in relation to this subject, the clearer and better understanding of the finer points of this project which allows me to have a better understanding of what is required / what is considered as necessary).
I will examine your points in further depth in the near future (I am a bit busy at the moment and am intending to spend some time over the weekend to consider these and other points).
In the meantime, if anybody has any other ideas or points of view then feel free to add them to this thread.
Ok, I have spent sometime considering the issues that @ctek provided. Whilst I appreciate that other people may have limited time and resources to spend upon the NS project, judging from the (lack of) conversation in relation to my previous suggestions, I believe that there is a lack of appetite for the provision of good, well-thought out and structured documentation.
I believe that the current issues surrounding documents and procedures could possible discourage some potential users from trying out / experimenting with NS.
I also understand that there would need to be some form of organisational structure for these documents (ie. the need for an editor, proof-readers and quality control processes) and again, this structure does need people to manager and overview the creation of NS approved documentation.
Also, due to the on-going development of NS and the incorporation of new interfaces and functionality, writing of any user-guides could be irrelevant at the present moment (what would be considered as a relevant guide today, could be irrelevant in the near future due to the above changes).
If people are put off due to lack of documentation to try Nethserver, they have no business running a server. If other open-source projects or even our own commercial product would have such documentation, there would be no problems in this world.
I do agree that this is a project to be taken seriously and agree with everything you stated, but please be proud of thedocs as they are. They are amongst the reasons why I went with Nethserver
Also, having now taken time to read the topic that spawned this; please do not document anything that is not Nethspecific. Please do document how to use Nethserver to accomplish tasks normally done with M$ or other expensive products and make sure they act alike in robustness. Do that and the community will do the rest … as long as you can say: get a proper Linux training and here are the specifics, you have done what you can. If you start training novices on how to setup a server, you are becoming a training product.
There is nothing wrong with that, but right now I see Nethserver as the only fair M$ replacement, which is a value in its own.
