[Tiki-devel] Dealing with old info at doc.t.o

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Tiki-devel] Dealing with old info at doc.t.o

Gary Cunningham-Lee
Hi,

At the June roundtable meeting just concluded, one of the things we
talked about was what to do with old information at doc.tiki.org. There
seemed to be a consensus that old information could just be deleted from
pages, and a link could be added in the page to the last page version
that contains that information.

The old information would still exist in the page's history of versions,
as an archive.

How old is too old to keep on the current page? Maybe no older than the
oldest supported version of Tiki, maybe back to Tiki 9 currently as some
one-click installers reportedly still install that version.

Any comments or opinions? If this idea seems good, then it could be
implemented page by page as people update information, etc.

-- Gary


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Dealing with old info at doc.t.o

Dr. Sassafras
+1 to everything

Perhaps one LTS behind the currently supported is a good general policy. It's not any more work keeping existing documentation, but it might perhaps people to migrate.

At the same time, irrelevant data just clutters the documentation, so I'm in complete agreement with removing anything pre tiki 9. As was pointed out, the history is always available.

Another approach would be to remove anything pre tiki 12, and perhaps have (auto-generated?) LTS history links, so there is a little button on the bottom if he page that has links to tiki 3,6,9. I'm sure a little plugin could probably do it without much effort. That way we keep documentation for up to the last supported version, but people can time travel if they need to. I think I would would vote for this later option in an ideal world.

Brendan

> On Jun 15, 2017, at 11:35 AM, Gary Cunningham-Lee <[hidden email]> wrote:
>
> Hi,
>
> At the June roundtable meeting just concluded, one of the things we talked about was what to do with old information at doc.tiki.org. There seemed to be a consensus that old information could just be deleted from pages, and a link could be added in the page to the last page version that contains that information.
>
> The old information would still exist in the page's history of versions, as an archive.
>
> How old is too old to keep on the current page? Maybe no older than the oldest supported version of Tiki, maybe back to Tiki 9 currently as some one-click installers reportedly still install that version.
>
> Any comments or opinions? If this idea seems good, then it could be implemented page by page as people update information, etc.
>
> -- Gary
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Dealing with old info at doc.t.o

Marc Laporte-3
In reply to this post by Gary Cunningham-Lee
Short answer: the same list as https://tiki.org/Download

So, as of now: 12, 15 and 16
When 17.0 is released: 12, 15, 16 and 17
Once 17.1 is released:  12, 15 and 17


Long answer:

1-  9.x is unsupported for the code, so it should also be unsupported
for the documentation.

2-  One-click installers offering Tiki 9.x   ->  When some parts of
the ecosystem fail at doing their job, let's not make things harder
for the other parts. Instead of compensating by adding more work /
overhead to the doc team, better use that time instead to coordinate
with the 1-click installers to help them offer supported versions. And
please steer 1-click installers to use LTS versions to reduce
workload.

3- To simplify things even more, let's not just remove very-old-stuff,
but also not-so-old stuff that applies to
not-currently-supported-version. For example, as soon as 16.x is out
of support (when 17.1 is released), pages like
https://doc.tiki.org/mPDF can remove all references to 16.x  This will
make the page cleaner, and reinforce that folks needs to pick between
15. x and 17.x

4- In an ideal world, we would have a snapshot of the docs when a
version goes out of support. The same way someone can download all old
versions of Tiki on SourceForge, it would be nice that they could do
the same for docs. But we don't yet have a smart way of doing that
yet. It's tricky because some pages are pretty similar for all
versions of Tiki. So a fix to a page could apply to 9.x and 12.x, but
for others, not so. Work is ongoing to be able to generate a PDF of
the documentation. Once we have that, we could generate one every time
a version goes out of support, and make it available like the old
versions of Tiki on SourceForge.  But I can suggest 100 things that
would be a higher priority than this.


Best regards,

M ;-)


On Thu, Jun 15, 2017 at 11:35 AM, Gary Cunningham-Lee
<[hidden email]> wrote:

> Hi,
>
> At the June roundtable meeting just concluded, one of the things we talked
> about was what to do with old information at doc.tiki.org. There seemed to
> be a consensus that old information could just be deleted from pages, and a
> link could be added in the page to the last page version that contains that
> information.
>
> The old information would still exist in the page's history of versions, as
> an archive.
>
> How old is too old to keep on the current page? Maybe no older than the
> oldest supported version of Tiki, maybe back to Tiki 9 currently as some
> one-click installers reportedly still install that version.
>
> Any comments or opinions? If this idea seems good, then it could be
> implemented page by page as people update information, etc.
>
> -- Gary
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



--
Marc Laporte

http://WikiSuite.org
http://PluginProblems.com
http://Avan.Tech

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Dealing with old info at doc.t.o

Gary Cunningham-Lee
Thanks. It will be tough adhering to this closely but at least we have
the guideline for when people do edit doc pages.

-- Gary

On 6/16/2017 12:07 PM, Marc Laporte wrote:

> Short answer: the same list as https://tiki.org/Download
>
> So, as of now: 12, 15 and 16
> When 17.0 is released: 12, 15, 16 and 17
> Once 17.1 is released:  12, 15 and 17
>
>
> Long answer:
>
> 1-  9.x is unsupported for the code, so it should also be unsupported
> for the documentation.
>
> 2-  One-click installers offering Tiki 9.x   ->  When some parts of
> the ecosystem fail at doing their job, let's not make things harder
> for the other parts. Instead of compensating by adding more work /
> overhead to the doc team, better use that time instead to coordinate
> with the 1-click installers to help them offer supported versions. And
> please steer 1-click installers to use LTS versions to reduce
> workload.
>
> 3- To simplify things even more, let's not just remove very-old-stuff,
> but also not-so-old stuff that applies to
> not-currently-supported-version. For example, as soon as 16.x is out
> of support (when 17.1 is released), pages like
> https://doc.tiki.org/mPDF can remove all references to 16.x  This will
> make the page cleaner, and reinforce that folks needs to pick between
> 15. x and 17.x
>
> 4- In an ideal world, we would have a snapshot of the docs when a
> version goes out of support. The same way someone can download all old
> versions of Tiki on SourceForge, it would be nice that they could do
> the same for docs. But we don't yet have a smart way of doing that
> yet. It's tricky because some pages are pretty similar for all
> versions of Tiki. So a fix to a page could apply to 9.x and 12.x, but
> for others, not so. Work is ongoing to be able to generate a PDF of
> the documentation. Once we have that, we could generate one every time
> a version goes out of support, and make it available like the old
> versions of Tiki on SourceForge.  But I can suggest 100 things that
> would be a higher priority than this.
>
>
> Best regards,
>
> M ;-)
>
>
> On Thu, Jun 15, 2017 at 11:35 AM, Gary Cunningham-Lee
> <[hidden email]> wrote:
>> Hi,
>>
>> At the June roundtable meeting just concluded, one of the things we talked
>> about was what to do with old information at doc.tiki.org. There seemed to
>> be a consensus that old information could just be deleted from pages, and a
>> link could be added in the page to the last page version that contains that
>> information.
>>
>> The old information would still exist in the page's history of versions, as
>> an archive.
>>
>> How old is too old to keep on the current page? Maybe no older than the
>> oldest supported version of Tiki, maybe back to Tiki 9 currently as some
>> one-click installers reportedly still install that version.
>>
>> Any comments or opinions? If this idea seems good, then it could be
>> implemented page by page as people update information, etc.
>>
>> -- Gary
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Dealing with old info at doc.t.o

Jonny Bradley-4
+1 :)

> On 16 Jun 2017, at 04:46, Gary Cunningham-Lee <[hidden email]> wrote:
>
> Thanks. It will be tough adhering to this closely but at least we have the guideline for when people do edit doc pages.
>
> -- Gary
>
> On 6/16/2017 12:07 PM, Marc Laporte wrote:
>> Short answer: the same list as https://tiki.org/Download
>> So, as of now: 12, 15 and 16
>> When 17.0 is released: 12, 15, 16 and 17
>> Once 17.1 is released:  12, 15 and 17
>> Long answer:
>> 1-  9.x is unsupported for the code, so it should also be unsupported
>> for the documentation.
>> 2-  One-click installers offering Tiki 9.x   ->  When some parts of
>> the ecosystem fail at doing their job, let's not make things harder
>> for the other parts. Instead of compensating by adding more work /
>> overhead to the doc team, better use that time instead to coordinate
>> with the 1-click installers to help them offer supported versions. And
>> please steer 1-click installers to use LTS versions to reduce
>> workload.
>> 3- To simplify things even more, let's not just remove very-old-stuff,
>> but also not-so-old stuff that applies to
>> not-currently-supported-version. For example, as soon as 16.x is out
>> of support (when 17.1 is released), pages like
>> https://doc.tiki.org/mPDF can remove all references to 16.x  This will
>> make the page cleaner, and reinforce that folks needs to pick between
>> 15. x and 17.x
>> 4- In an ideal world, we would have a snapshot of the docs when a
>> version goes out of support. The same way someone can download all old
>> versions of Tiki on SourceForge, it would be nice that they could do
>> the same for docs. But we don't yet have a smart way of doing that
>> yet. It's tricky because some pages are pretty similar for all
>> versions of Tiki. So a fix to a page could apply to 9.x and 12.x, but
>> for others, not so. Work is ongoing to be able to generate a PDF of
>> the documentation. Once we have that, we could generate one every time
>> a version goes out of support, and make it available like the old
>> versions of Tiki on SourceForge.  But I can suggest 100 things that
>> would be a higher priority than this.
>> Best regards,
>> M ;-)
>> On Thu, Jun 15, 2017 at 11:35 AM, Gary Cunningham-Lee
>> <[hidden email]> wrote:
>>> Hi,
>>>
>>> At the June roundtable meeting just concluded, one of the things we talked
>>> about was what to do with old information at doc.tiki.org. There seemed to
>>> be a consensus that old information could just be deleted from pages, and a
>>> link could be added in the page to the last page version that contains that
>>> information.
>>>
>>> The old information would still exist in the page's history of versions, as
>>> an archive.
>>>
>>> How old is too old to keep on the current page? Maybe no older than the
>>> oldest supported version of Tiki, maybe back to Tiki 9 currently as some
>>> one-click installers reportedly still install that version.
>>>
>>> Any comments or opinions? If this idea seems good, then it could be
>>> implemented page by page as people update information, etc.
>>>
>>> -- Gary
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Dealing with old info at doc.t.o

Jean-Marc Libs
In reply to this post by Marc Laporte-3


On Fri, Jun 16, 2017 at 5:07 AM, Marc Laporte <[hidden email]> wrote:
Short answer: the same list as https://tiki.org/Download

So, as of now: 12, 15 and 16
When 17.0 is released: 12, 15, 16 and 17
Once 17.1 is released:  12, 15 and 17

+1
(everything else is in the page history anyway if anything important was lost)


Long answer:

1-  9.x is unsupported for the code, so it should also be unsupported
for the documentation.

+1

2-  One-click installers offering Tiki 9.x   ->  When some parts of
the ecosystem fail at doing their job, let's not make things harder
for the other parts. Instead of compensating by adding more work /
overhead to the doc team, better use that time instead to coordinate
with the 1-click installers to help them offer supported versions. And
please steer 1-click installers to use LTS versions to reduce
workload.
+1

3- To simplify things even more, let's not just remove very-old-stuff,
but also not-so-old stuff that applies to
not-currently-supported-version. For example, as soon as 16.x is out
of support (when 17.1 is released), pages like
https://doc.tiki.org/mPDF can remove all references to 16.x  This will
make the page cleaner, and reinforce that folks needs to pick between
15. x and 17.x

I like it in principle, but I had a look at the https://doc.tiki.org/mPDF page and I feel removing Tiki16 references is more work than its worth, and it would add vagueness, not clarity anyway.
Saying «this changed in Tiki16.2» is no endorsement of using Tiki16

Examples from the page:
First example:
the Tikiroot (main installation):
     /myproject/tiki16

→ Obviously we should replace with a generic solution ( /myproject/tiki )

Second example:
Up to Tiki 15.x (and up to 16.1):
  • blah blah
Since Tiki 16.2:
  • Other blah blah

→ Removing « and up to 16.1 » and then replacing «Since Tiki 16.2 » with « Since Tiki 17 » then «Since Tiki 18 LTS» brings no value and is confusing, IMO.
Just leaving it as it is is less work for acceptable result.

So, I don't see the simplifying factor here and I'd just let people use their common sense.
 

4- In an ideal world, we would have a snapshot of the docs when a
version goes out of support. The same way someone can download all old
versions of Tiki on SourceForge, it would be nice that they could do
the same for docs. But we don't yet have a smart way of doing that
yet. It's tricky because some pages are pretty similar for all
versions of Tiki. So a fix to a page could apply to 9.x and 12.x, but
for others, not so. Work is ongoing to be able to generate a PDF of
the documentation. Once we have that, we could generate one every time
a version goes out of support, and make it available like the old
versions of Tiki on SourceForge.
+1
  But I can suggest 100 things that
would be a higher priority than this.
+1

Cheers,
Jyhem


Best regards,

M ;-)


On Thu, Jun 15, 2017 at 11:35 AM, Gary Cunningham-Lee
<[hidden email]> wrote:
> Hi,
>
> At the June roundtable meeting just concluded, one of the things we talked
> about was what to do with old information at doc.tiki.org. There seemed to
> be a consensus that old information could just be deleted from pages, and a
> link could be added in the page to the last page version that contains that
> information.
>
> The old information would still exist in the page's history of versions, as
> an archive.
>
> How old is too old to keep on the current page? Maybe no older than the
> oldest supported version of Tiki, maybe back to Tiki 9 currently as some
> one-click installers reportedly still install that version.
>
> Any comments or opinions? If this idea seems good, then it could be
> implemented page by page as people update information, etc.
>
> -- Gary
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



--
Marc Laporte

http://WikiSuite.org
http://PluginProblems.com
http://Avan.Tech

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Dealing with old info at doc.t.o

Dr. Sassafras
It's of significant concern of mine that the documentation will fail to fulfil the following with the proposed changes:

1. Fail to assist people in upgrading. Being able to view comparative documentation brings a confidence to being able to upgrade and assists in identifying [mods] where attention is required, or in problem solving issues after upgrades.

2. Documentation will fail to present an accurate picture of how many versions a feature has been in tiki for, or when a [mod] had been made to that feature. This is important information as it helps people form an idea of how stable a particular feature is. I personally will treat very old features, modern but stable(few version old features), and brand spankin new ones a little differently. I might spend a little extra time testing very old features if it's something that is perhaps not well used. I may rely on my planning on 'modern and stable' features as reliable enough to count on. New features on the other hand I may test more, or expect a few bugs especially if used in conjunction with uncommon features.

Removing the documentation that assists people in troubleshooting issues and upgrading from unsupported versions are unwelcome changes imho.

I think everyone agrees that documentation from versions that people are not upgrading from is unnecessary and worth removing.

I would personally be much more comfortable in removing tiki-9 docs if there was a handy way of pulling up the old documentation (through a history link specific to that version) but it's really a minor issue for me, so would be happy to leave such a decision in the hands of the people updating the documentation.

Removing minor release versions between the most recent LTS versions though I'm opposed to. It's still very conceivable that people are trying to upgrade from those versions and tracking changes in those versions would be of value to me, even if not using them.

Alternative solutions to these 2 issues with removing recent STL and the most recent unsupported LTS would be eagerly received.

Brendan

> On Jun 16, 2017, at 8:43 AM, Jean-Marc Libs <[hidden email]> wrote:
>
> else

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel