Skip to content

meaning of Summary #616

@jans23

Description

@jans23

Currently the field Summary is in section Revision so from this layout I understand that for each change users should give that change a Name and a Summary.

Image

The issues I see:

  • Two fields are unusual and IMO a single field would be sufficient
  • While editing both fields are not cleared so in practice you end up not updating those which renders the history useless (think of git would use a default commit message if you don't change it explicitly). This is the main issue I experience.
  • The history shows the Summary but not the Name. So what is the Name good for?
  • In the search for a document the default field is Summary. IMO this doesn't make sense if the Summary is specific per revision while the user is searching for a document
Image Image

I suggest the following solution:

  • Move Summary out of section Revision.
  • So we use Name for Revisions only and ideally rename that field to Changes
  • Show Name/Changes in the History instead of Summary
  • Change the UI so that user must enter a Name/Changes when changing a document revision and can not simply keep its content of the previous revision

What do you think?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions