DevApp Content Life-cycle [was: Re: Wiki ideas]

[Nick Loeve]

Sean Wheller wrote:
> On Saturday 02 April 2005 02:19, Nick Loeve wrote:
> 
>>Sean Wheller wrote:
>>
>>>On Friday 01 April 2005 11:11, Mark Shuttleworth wrote:
>>>
>>>>Let's see what we can get done at UDU, but in parallel, let's see what
>>>>you guys come up with.
>>>
>>>Hello Mark, Corey,
>>
>><snip><snip>
>>
>>
>>  - Surely security can be achieved with other technologies - i have had
>>
>>    a lot of experience with PHP and would be willing to help share my
>>    experience with PHP and security issues
> 
> 
> I think we are in the right here, but it is also hard to change perceptions. 
> If James and team don't want then I kinda get the feeling that we could be 
> fighting a losing battle unless we host externally.

Agreed, and i do not really mind at all. I love most of the technology 
that Ubuntu and it's developers are pushing and would like to become 
more proficient using those tools.

> 
> 
>>  - I do not think that a web based solution is the way to go for
>>    everything. I know that for a large document (or even for something
>>    as big as the quickguide) it is more manageable if editing is
>>    offline)
> 
> 
> Agreed. As I see it, a web-based front end is just one interface. Under the 
> objective I never mentioned that the only editing interface would be 
> Web-based. I do state that the Authoring repos is a working copy of svn. The 
> way I see it is that we will merge changes from this working copy into our 
> svn. Think of the web-app as just another user/author in the team. Just an 
> author on steroids because it is actually the work on many more people.

Ok, that makes sense.

> 
> The nature of the solution I suggested in that it enforces structure from the 
> content to the organization of the information architecture. This makes it 
> far more managable than what we have now.
> 
> 
>>And after all that, to get back to another of Sean's point, those
>>working on this project will not be creating documentation. Maybe what
>>we need is a seperate subteam 'Ubuntu Documentation Technology Team' or
>>something. That way energy is not being sapped from the documenation
>>effort, but those that want to contribute to both seperate ideas
>>(creating docs, creating a system for creating docs) are free to do so.
>>
>>At present the doc team is pretty small, so i do not know if there is
>>enough man power to create another seperate team, but over time the
>>'Ubuntu Documentation Technology Team' could attract existing or new
>>Ubutnu developers, and build closer ties with those that are in the know
>>in regards to building software for Ubuntu, deploying software for
>>Ubutnu and maintaining software Ubutnu.
>>
> 
>  If I understand Mark correctly, he is saying let the doc team forge an idea 
> and present it, then he will muster devels to support it. From our part we 
> need to to the investigation. I suggest we create a specification document 
> based on our resarch and use that to present. Once devels get involved we can 
> assist in ways we can, if we wish.

Ok great. I originally wanted to do some development for Ubuntu, but got 
into the doc team because (with no experience of Debian development etc) 
the barriers to entry were lower. I would really love to be part of any 
development for this idea, but have also enjoyed and want to keep 
enjoying working with the team on documenation and discussing ideas 
surrounding the generation of documentation.

> 
> I will start preparing a basic document for us to collaborate on. In the 
> interim I think it would be productive if people search for solutions and 
> post links to the list under this thread. We can then discuss each solution 
> and narrow down the list to the top 3 candidates.

Agreed. Thats a great idea, thanks for taking on the setup.


Cheers,
trickie (Nick Loeve)