I don’t think so. If you sign out on Wikipedia, you will be logged out here eventually, but for performance reasons your login status can’t be checked all the time, so it will take time (a day, I think?) for the logout to reach here.
We should probably unarchive that project and make it a parent project for the extension via Herald.
Given the importance of connecting the forum with the wikis, could one possibility be to find a contractor to develop this extension? After the community review, if this is consistent with its outcome.
I mean, it’s great of the extension can be developed by volunteers, but if there is more pressure to have this feature, it is unfair to put this pressure on volunteers. It doesn’t seem like a too complex project either? Although what do I know.
I know this is extremely well meant, but it may be mistaking what drives community motivation and enthusiasm vs unwelcome pressure.
We should use staff resources to ensure fast, friendly, effective review + implementation of community patches and pull requests.
We should promote and support “not too complex”, high-demand, cleanly defined technical work as ideal things for devs in our open community to take on. Especially tasks like this, related to an existing tool that thousands of community members have experience with (and thousand more open-source devs who might not have had a way to contribute to MW before)
You can still assign bounties or other recognition to a successful implementation, to indicate enthusiastic support. But trapping the development in a contract with a single person, that then gets obscured behind & contributes to a social “staff-community” divide, and adds a bottleneck, historically has not strengthened the community (or even been faster than the alternative). [and of course the current extension was built by Sam, driving home the point that the divide is unnecessary / in our minds ]
I fully support and agree with the opinion that we should cause the app Discourse to have some acceptance and usage as a genuine resource for the community. In my opinion, the other resources do not come close to matchning the usefulness, benefits and positive role of the app Discourse.
the only concern here is the possible encroachment of Wiki Harrier-HAwks who might encroach here. if you want to know what that is, go look them up under WikiFauna. don’t worry, you have WikiPrairie Dogs and WikiShepherds, who can help to deter the WikiHarrier-Hawks.
@Samwilson do you have a roadmap of what needs to be done for the extension to be deployed?
I think the main thing is to figure out what it should actually do! At the moment, based on what we talked about a few years ago for Space, it provides a Lua module for retrieving info at parse-time. It sounds like there might be more desire for things like notifications, so that’d be more development work. But the stuff so far seems to work fine.
I’ve installed it in a demonstration wiki, so if anyone wants to have a play with it feel free to edit anything:
- Example output: https://genealogy.toolforge.org/wiki/Project:Forum
- The module: Module:Discourse - Genealogy Demo
- Report feature requests at: Discourse
@Samwilson , I had no idea about this resource, or that it existed. i truly appreciate your posting this link here. please feel free to keep us posted, to provide additional links, or to let us know any other news, updates, projects, resources, links, or of course anything similar. thanks very much!
So, should we just start working through the deployment checklist? Pragmatically, it’s easier to do that anyway while the extension has less functionality and is thus smaller; plus, feedback early, feedback often, and it’s hard to get feedback without actually deploying the thing.
This reply to @Xeno_WMF is related to this discussion:
I’ll confess that I’m not tech-savvy, but I’m putting on my project management hat to ask: how are things going? What’s the current status and what kind of support/resource can we offer? @Tgr and @Samwilson
I’ve reactivated the Discourse Phabricator project (and added some more notes to its description), and will start working through the deployment checklist.
I feel like the caching of Discourse data on the MediaWiki side might be the tricky stuff; we have to find a balance between it staying up to date, and it not making too many requests to Discourse. Currently, it allows any URL path, and caches the response for an hour. But anyway, that can be discussed elsewhere.
Who says July is too hot for miracles? Great news.
I’ve created a tracking task for pre-deployment activities: ⚓ T313375 Prepare Discourse extension for WMF deployment
I noticed all the development and deployment info is on WMF infrastructure,
and I wonder if notifying people on the Discourse side would be good
just in case someone else has interest in having this elsewhere?
*(there is at least one MediaWiki farm that would benefit from this
I mentioned it over there last year, but you’re right there might well be other people interested in helping test and develop.
Deploying to Wikimedia wikis is unlikely at the moment, I think, but we could perhaps look at connecting Wikispore, if that’s a good idea? So that we can start experimenting with how Discourse can best work alongside MediaWiki.
That would be awesome as we started to prep for few hackathons just now on Wikispore.org