Ethan: > I think I put the building instructions in the README but if not I > can help you get it built locally. Alternatively you could push to > your fork on GitHub and enable Actions and Pages for your fork to > have GitHub Actions build it whenever you push.
That sounds a little too complicated. Ethan: > If we do want to improve the wiki, I'd like to see it upgraded to a > newer version of MediaWiki, so that it can look more modern and have > integration of Visual Editor. The current GNUstep wiki is easier on the eyes than the new, flat look of Wikipedia. Not sure if this is what you mean, but there are different skins that aren't flat.[1][2][3] VisualEditor may be nice for those who don't want to learn the syntax. If only MediaWiki could use markdown. :) Looks like there is an extension for this, but I'm not sure if it's any good.[4] Riccardo: > Of course, one could thing the whole software migrated to GitHub, but > well, I wouldn't. rather a nigthmare, wouldn't it be? Right: GitHub has Discussions, but I've found them lackluster at best. Mailing lists tend to keep the noise low. Riccardo: > The Wiki seems fine for organic contributions: it is thought exactly > for that, easy change, revert, collaborate within predefined > templates. > A website is more static and maintained by less people. I think it > should be rather KISS. > I feel the Wiki is perfect for things like build instructions, > screenshots news, description of apps, tools and information which > points to many other projects related to gnustep. > about the github site opinions differ. Some seek it as a replacement > for gnustep.org. I am against that and I don't feel what is in there > is up to it either. > No easy answer. It looks like the easy answer is in your first paragraph. Riccardo: > Documentation has always been an issue for Open Source projects and > now even Apple documentation is by far not what it has been at the > peal of 15 years ago. > I loved when it was off-line, cross-linked and smooth between > reference, tutorials and guides, all in the help of XCode. I find the new Cocoa documentation unbearable. The conceptual docs, which were one of the best parts, are now relegated to a "retired" archive. Were the gains of Swift and UIKit worth it when we see what was lost? Riccardo: >> Thinking back to the "legacy" Cocoa documentation, it was one of the >> most delightful and comforting aspects of it. It was thoughtfully put >> together and it was complete. GNUstep may have implemented many of >> Cocoa's technical accomplishments, but has fallen short on this less >> glamorous, yet critical, side of software. >> > Apparently, we fully agree on that. A small dream would be to > automatically convert autogsdoc information to HelpViewer format. > Past attempts (including the example provided) were unusably buggy and > adding a new backend to autogsdoc is not easy either. Offline is a big plus for me as a browser distracts me too often. I am not familiar with autogsdoc, so don't take the next paragraph too seriously. I have been playing with Zeal,[5] which downloads docsets from Dash.[6] I'm not sure if it is feasible to have GNUstep reference documentation in that format, but it may be worth looking at in the future. Maybe someone could build a GNUstep app that can browse these docsets. There are references to Objective-C in Kapeli's Docset Generation Guide too.[7] Either way, I don't think the reference documentation is where the biggest wins can be made for now. It seems like a more complicated issue and no one is going to care about the reference documentation if they're confused about what GNUstep even is. Ethan: > I've never used Projects either. I'd like to do something where people > can edit the todo list without having to push commits to GitHub Riccardo: > But for tasks tracking I prefer a real tracker, e.g. issue Tracker of > GitHub (or equivalent) rather than managing a file with "commits" > every time. > since we are on GitHub, we should get away from savannah (as much as I > dislike that personally!). But for coherency it should be migrated > somehow. E.g. all tasks reviewed except in-progress tasks which we > should prioritize to close them down > I don't think a file you need a commit or save (that's what Wiki does) > is an efficient way to do it. Xavier: > Sergii Stoian use Github's Project for Nextspace. He creates tasks and > adds bug reports in various project steps. Okay, this[8] is pretty neat. I hate the board layout, but the table and roadmap don't look bad.[9] Not sure if the admin has control over the defaults, but it allows users to modify the view without changing it for everyone.[10] Seems to play nice with Issues on GitHub too. Riccardo: > Email for me is fine. For work on the Wiki, just ask for an account. > It is not public because we where overwhelmed with spam accounts. > > We also have a webmaster mailing list. Might make sense to use it, if > you wish. Thanks. I'll be in touch, though it may not be for a couple of weeks. I'll check out that mailing list and start a new, more focused thread over there. [1]: https://www.mediawiki.org/wiki/Skin:Timeless [2]: https://www.mediawiki.org/wiki/Skin:Vector [3]: https://www.mediawiki.org/wiki/Skin:MonoBook [4]: https://www.mediawiki.org/wiki/Extension:WikiMarkdown [5]: https://zealdocs.org/ [6]: https://kapeli.com/dash [7]: https://kapeli.com/docsets [8]: https://github.com/trunkmaster/nextspace/projects [9]: https://github.com/users/trunkmaster/projects/6/views/1?layout=table&groupedBy%5BcolumnId%5D=Status [10]: https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project -- Luke Lollard
