You need to use a plugin (or fix core!) so that the original is not unpublished when a draft of changes is saved. This happened a lot over at WP until they finally put a plugin to handle it.
1 Like
Agreed. In fact, the proposal was made on this basis:
Previously, our documentation site has just been a normal, vanilla ClassicPress site. This has worked well but it has meant that anyone who contributes to our documentation needs to have a privileged user account on the site.
So it previously “worked well” and now it doesn’t. The experiment failed. And if there’s an issue with having several people working on the docs, we should learn how to manage that with the tools that CP puts at our disposal (plus, if necessary, a plugin like User Role Editor).
1 Like
You do have to be careful about plugins on the official site, since the updates could be a security issue.
Of course. But the one I suggested, for example, is of very long-standing and I use it on almost every site I manage (including on sites where there are many contributors).
Additionally, you have admin access to the docs site, you are welcome to update things there as you see fit.
While I indeed have access, no page can be edited, it misses the editor and says “Edit on Github”
I am not sure how that is loaded, since neither theme nor plugins used on the site feature any code for that.
To have any chance to edit these pages we’d need this GitHub bridge disabled. How do I do that?
Ok wait, I stand corrected.
The theme does include code for that, in the template files.
Thus I think theme switch will do the job.
I will put the site under maintenance mode once I am doing real changes.
I have the DOC source material ready.
The DOC itself is created from code taken from CP directly and thus open source. No issue.
There are comments on each DOC when the DOC exists as well in WP, example:
I can import all those comments (whatever existed up and until WP 4.9) into our own DOC as well.
However, of course, I can’t import the users who authored them because those are WP Users, not CP Users.
Thus, if I import, it will be a comment added by Contributed by — 23 seconds ago — Edit
See screenshot of my local:
Legally this is no issue, as all those comments are GNU Free Documentation License v1.3 - GNU Project - Free Software Foundation, but, it might be not nice. Thus I will wait with them, since I can import the comments at any given moment also after creating the main doc, there is no requirement to do so during the main import or “asap” at all.
The question you’ve asked does not have a definitive answer, unless someone can find a policy on wordpress.org that makes clear the legal basis on which comments are made. But I can’t find such a document, so my current analysis is as follows.
First, the person making any such comment owns the copyright to the comment. (No document on wordpress.org could change that.) But as they don’t leave these comments in private, it is clear that they are intended for public consumption, and so wordpress.org has a license to keep and display them on its site. (This is essentially how the law views any comments on any publicly-visible website.)
If wordpress.org had expressly adopted a specific license, such as a Creative Commons license, then we would know the extent of the license granted by each person who leaves a comment. In the absence of such an express license, we are left trying to figure out the precise extent of that implied license, and that’s where things get murky.
This has never been tested in court, and it’s hard to be sure what should be implied. But I think there are probably three possibilities.
One is that the license has been granted solely to wordpress.org. If this were true, then copying and displaying such comments on a ClassicPress site would break the terms of the license. I don’t think that this interpretation makes much sense, however, for comments left on wordpress.org. Unlike comments on a blog, those comments are not really being made for the benefit of wordpress.org; they are being made for users of the code being commented on. Indeed, there are — and have been for years — several services that scrape both code and comments from wordpress.org, and this interpretation would render them all illegal. And, of course, the code is open source. So I strongly doubt that this interpretation is correct.
At the other end of the spectrum, it might be said that because the code itself is open source and licensed under the GPL, then so are all the comments. But I don’t think this interpretation would fly either. There is a big difference between code and comments — they are literally written in different languages — so I think this interpretation involves a logical fallacy. Most importantly, the GPL allows code to be used for profit, whereas I think it’s highly doubtful that most contributors of comments would be happy to see their comments sold for profit.
Having eliminated the other options, it follows that’s what’s left is the most appropriate approach. This focuses on the purpose for which the comments are made, which is clearly to enable the code to be better used and understood. So, in my view, provided that purpose is maintained, and provided also that the comments are not used as part of something that is used for commercial gain, then we should be free to have the comments on a ClassicPress site if we also include attribution to the original commenter.
You say that you can’t do that, but actually that’s not true. Those who comment leave a username, which is hyperlinked to an account on wordpress.org. We just need to keep those usernames and hyperlinks in place.
5 Likes
Tanks a lot for this insight
I found they publish those comments under GNU Free Documentation License v1.3 - GNU Project - Free Software Foundation and it seems as far I am able to understand it’s ok to use them
However I have as of now only a dump of the comments without user attribution
Thus I’ll wait with adding them and try to get either a dump or a scrape with attribution
I think then we’d be safe.
As it’s not an elemental part of the doc (many comments are simply very old) and with current doc status we only gain quality by adding even the tiniest part it’s also not mandatory to have them in the first “run”, I think.
I can always import them later since luckily they’re native comments.
Thanks again!!
Where have you found that? The GPL would certainly apply to comments included within the code. But, unless there’s some statement somewhere on wordpress.org that specifically refers to comments left on the site, then the GPL would not be relevant. (In fact, if there is such a statement but it can’t easily be found, it won’t apply either.)
1 Like
On their codex comments form at the bottom
If you log in and see the comment form, it’s just under it:
- NOTE: All contributions are licensed under GFDL and are moderated before appearing on the site.
1 Like
Oh, perfect! I would expect to see such a statement in the footer for everyone to see, regardless of whether someone is logged-in or not, because (as we now see) the terms of the license are important not just to the person making the comments.
If we allow comments on our own site, we should make the license statement viewable by everyone, regardless of whether they are logged-in or not.
1 Like
Also noticed that Ian Dunn’s comment on this specific function (i.e. how to avoid using get_user_meta( $post->ID, 'foo', true ) in favor of $post->foo) is highly misleading, because the latter method always returns null if the metadata is being retrieved from the database.
1 Like
This is one of the issues that make me question to even add them
Many comments are either old or totally off the grid.
I think (I think too much) we’re - for now at least - probably not worse off if we hold on adding those comments. Better than adding them just for the sake of being there.
Some comments are extremely valuable, however I’m not sure this justifies adding other, eventually wrong comments.
1 Like
I was beginning to wonder the same thing.
I agree with this.
Agree with this too - and the same goes for granting access to the docs site - users who have access to any official site need to be vetted beforehand.
Having said that, I think it’s time to roll back the git integration stuff on the docs site and give people who are interested in maintaining the docs access to do so. I propose to add @anon66243189 and @timkaye if one/both of you are interested and willing to help out with this.
I wouldn’t recommend doing a theme switch on the docs site until there is actually a new theme that is ready to go (and yes, this should be done at some point to add a proper menu and other things, but probably best to split that into a separate project to keep things moving in steps). Instead, I will remove all of the git integration from the site’s code later today.
As far as comments, I like the way the comments work on the main site: any blog post that can have comments enabled is posted as a linked forum thread and the comments are managed via the forum.
2 Likes
Yes, please, to being added.
Docs site has already been updated, we just need to add back the Discourse plugin for SSO. Which is planned for tomorrow, since we all kind of ran out of time today.
3 Likes
