[pmwiki-users] using PITS as a project manager

[John Rankin]

On Tuesday, 8 February 2005 6:57 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>Here's a candidate: how about figuring out how to handle PmWiki's
>FAQ document, or developing a way to index FAQ and PITS entries together
>and still make sense of them?  
>
>Take a look at http://www.pmwiki.org/wiki/PmWiki/FAQ and you can 
>see that it somehow "doesn't work".  One problem is that with all of the
>questions combined it's not easy for an inquirer (or respondent)
>to easily track individual questions.  Tracking items is what PITS
>is good at, but the current PITS form isn't situated around supporting
>a FAQ.

Do you mean something like the following:

- each question is its own page, entered and updated through a form

- we define a list of categories into which questions might fall

- the FAQ form contains a series of check boxes for categories

- we use the category markup to let us see questions arranged by category
>
>This is also mentioned in PITS #00204.
>
>For *real* bonus points, the system ought to be able to integrate issue
>tracking, FAQ documents, *and* the cookbook.  Right now that integration
>takes place via the pmwiki-users mailing list, but the problem with the
>mailing list is that there's not a good way to attach a status (open,
>awaiting feedback, closed, assigned to XYZ) or identifier to a
>thread.

- we use the same category scheme for PITS entries and cookbook entries

- one also wants a simple mechanism for creating see-also references among
  PITS, FAQ and recipes (and possibly see references within each group)

- for example, on a FAQ page, automatically list all the recipes with the
  same categories, with a teaser paragraph summarising the capability

- OTOH, mailing list threads are excellent because they are push not pull;
  I'm not sure it's a good idea to move them to the wiki
>
>> > However, changing the template will seriously break editing of
>> > existing records.
>> 
>> You could add button that, when clicked, causes the template to become
>> immutable without some extraordinary action. That would at least
>> mitigate people shooting themselves in the foot.
>
>Somehow I think it's more important to find a way such that templates
>can be changed -- it's unrealistic to expect that people will get the
>template right the first time, or that templates won't need to evolve over
>time. 

I agree. At the moment, what happens is that editing an existing page via
the form will get lost at the point where a field is inserted or deleted.
However, this is an implementation detail and shouldn't be a showstopper. 
I felt I had earned a rest after working out how to take an existing page 
apart.

The work-around is to use the Edit Page to align old pages with the new
template, but this is not ideal.

My idea is that one would have a templates group, with an edit password,
so only administrators can edit the templates.

>(BTW, the implementation of PITS is such that changing the
>template wouldn't break things.)

In the sense that the fastest, most reliable parts of a system are
the ones we leave out.

-- 
JR
--
John Rankin