Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: The future of Textpattern docs; intentions & plans; RFC
Bloke wrote #340344:
The problem with that approach is that we need everyone who contributes to have a Txp login. That’s not something I relish and would prefer an external site handles authentication for us to suck approved content changes in.
Hmm, aren’t we confident in our user privileges management? ;-)
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
etc wrote #340355:
Hmm, aren’t we confident in our user privileges management? ;-)
Hehe. If docs is a silo server, then I’d be happier.
But I was thinking more about the overhead of self-registration, unless we want to put in a process for people to manually request an account first?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
From a logistics point of view, there’s an A-to-B route for marked-up documents (e.g. GitHub) to a web-viewable & searchable site (e.g. Read The Docs). When A-to-B-and-A-to-C (where C is e.g. compilation to an offline format like EPUB or PDF), the ‘A’ part is still maintained as the one true source.
‘A’ (GitHub) can have a lot of heavy lifting added to it: we can convert files from the origin format (e.g. Markdown) to multiple other things (e.g. Read The Docs-ready files…EPUB compilation…PDF export…Textpattern import XML…compiled HTML…etc) concurrently. There’s a whole raft of pipeline stuff we can tap into that we’re not using at the moment. That pipeline stuff makes exporting to ‘B’, ‘C’ and anything else deemed useful.
I’d really like to have a public / transparent inbox and working area (‘A’, e.g. GitHub) that anyone can peruse and comment on without the need to maintain a Textpattern for that purpose of user management. That material goes into the conversion blunderbuss and lands at its destinations (plural), wherever that may be.
I’m absolutely not saying we need to may any old format available, but one person’s trash is another person’s treasure. If we make EPUBs and PDFs automatically, it takes practically zero person time. If they don’t get downloaded or used, we turn that part off.
In my experience, PHPBU does a very clean & clear job of offline docs: www.phpbu.de/documentation.html
I’m not quite yet in chronically online territory, but if can read some docs away from these infernal desktop screens and not use a browser (e.g. EPUB or PDF), that has value. Some organisations might have internal practices where ebooks are permitted in systems that aren’t connected to the internet.
Bloke wrote #340356:
If docs is a silo server, then I’d be happier.
Can you clarify what you mean by silo server please, Bloke? Thanks.
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
gaekwad wrote #340357:
That pipeline stuff makes exporting to ‘B’, ‘C’ and anything else deemed useful.
This. I’d much rather have a public changelog than have to do it inside Textpattern.
Can you clarify what you mean by silo server please?
I only meant that if we’re allowing self-registrations that any script kiddie can set up and then change docs and/or wreak havoc, I’d rather not have the docs located on the same physical space as important site assets like textpattern.com. It only takes one person with a crappy password, and privilege escalation is a possibility.
It’s a moot point if we’re doing stuff externally and pushing to Txp. Another plus.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
Bloke wrote #340359:
I only meant that if we’re allowing self-registrations that any script kiddie can set up and then change docs and/or wreak havoc, I’d rather not have the docs located on the same physical space as important site assets like textpattern.com. It only takes one person with a crappy password, and privilege escalation is a possibility.
Perfect. Thank you.
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
Bloke wrote #340356:
But I was thinking more about the overhead of self-registration, unless we want to put in a process for people to manually request an account first?
We would obviously create accounts for volunteer forum members. As if there were a long queue.. :-)
But I’m fine with specialised third-party tools too. Whatever fits better.
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
etc wrote #340365:
We would obviously create accounts for volunteer forum members.. :-)
That’s how I imagined it.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
colak wrote #340366:
That’s how I imagined it.
How do you envision next the reporting and (preliminary) suggestions for fixes and improvements (the action that currently uses GH as linked at every doc page?
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
phiw13 wrote #340367:
How do you envision next the reporting and (preliminary) suggestions for fixes and improvements (the action that currently uses GH as linked at every doc page?
I don’t. Preliminary suggestions could happen in the forum or as a comment.
I can fully understand why github is currently the most convenient platform for it. Admittedly, I want my convenience too. What are we losing in return for that?
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
colak wrote #340370:
I don’t. Preliminary suggestions could happen in the forum or as a comment.
Good. I really like that.
(and GH has long been a, the, point of friction for me in that docs pipeline.)
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
colak wrote #340370:
I can fully understand why github is currently the most convenient platform for it. Admittedly, I want my convenience too. What are we losing in return for that?
1. Proper, atomic, multi-user version control.
Arguably we don’t have many contributors (which, as phiw13 says, may partly be due to the git requirement) so it’s not a huge showstopper.
2. Distributed changes (linked to point 1, but stomping on another users’ feet is less likely in a BCS compared to doing it in Txp).
3. Once it’s in Textpattern in Textile or Markdown, we’re limited on exporting it as either of those formats, or html, unless we rely on a back-conversion. And we don’t have change hooks unless we build a plugin to handle it.
If content is stored in a central repository somewhere, we have more options to autonomously reformat it and push it to multiple other platforms, as required (one of which is Textpattern).
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: The future of Textpattern docs; intentions & plans; RFC
colak wrote #340370:
Preliminary suggestions could happen in the forum or as a comment.
I can fully understand why github is currently the most convenient platform for it. Admittedly, I want my convenience too.
We already have the forum as a feed-in mechanism for anyone to propose, edit & change docs stuff – in that sense nothing will change – unless it’s hideously complex or enormously time-consuming, that works just fine. The logistics of that route typically involve Person A (not a direct contributor to GitHub in this example) proposing / suggesting / correcting / creating stuff, and Person B (a more seasoned GitHub contributor in this example) doing some / most / all of the lifting. There are multiple Persons A and multiple Persons B for that route in, so it’s not the case that a single person (Person?) would be overworked.
It’s more efficient if Person A can modify the docs directly and raise a pull request, but there’s a hurdle / minimum ride height for that, so I totally understand the resistance (if that’s the right word).
Offline