Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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.
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