Talk:Main Page

From WikEmacs
Revision as of 15:19, 3 June 2013 by Ciaran (talk | contribs) (→‎Which emacswiki.org topics to work on?: search engines, page edits, and alexa.com)
Jump to navigation Jump to search

IMPORTANT: Offline discussion

There is a Google group for discussion of the site: https://groups.google.com/forum/?fromgroups#!forum/wikemacs so we should probably favor posting there. PhilHudson 16:16, 26 March 2012 (EEST)

IMPORTANT: Content Quality guidelines

I think before flame wars and fights among members, we should form proper/strict guide lines for each aspect of the site. DePuy Pinnacle Lawsuit Wikipedia has very strict rules about that., even their bots can tell the content quality of a page. we can create articles in "WikEmacs" Namespace. Kindahero 23:57, 1 April 2012 (EEST)

Wikipedia has lots of rules today, but it started with very few rules and they invented the rules as they became necessary. It's impossible to predict what problems will be encountered. I'd suggest that rules only be made when it becomes clear that one is necessary. Ciaran 15:24, 29 January 2013 (EET)

Structure

I would like to structure the Main Page in boxes like here [1] the Featured Article/Project. Any objections? And maybe User:Bozhidar should write some lines about the relation to the "old" EmacsWiki?--Kenda 19:58, 24 March 2012 (EET)

This seems like a good idea. Might help us utilize better the screen estate. As for the relation to the EmacsWiki - it is more or less non-existing. We have the permission from Alex (kensanata) to migrate any content we choose to, but they won't be supporting us in any way. Bozhidar 20:28, 26 March 2012 (EEST)

Markup Conventions

Wikipedia linking convention

Could/should we have a convention for formatting and placement of wikipedia links on pages? PhilHudson 22:37, 24 March 2012 (EET)

EmacsWiki linking convention

Similar question to Wikipedia wrt EmacsWiki PhilHudson 23:06, 24 March 2012 (EET)

Describing Modes and Packages

Naming Conventions

I'd like to suggest *not* suffixing (links to) modes with "-mode". Thus: "org" not "org-mode". For consistency I've been adding links titled "org-mode" until now, since that one was already created when I started. PhilHudson 22:09, 24 March 2012 (EET)

Agreed, let's use the "friendly" name of a package. I'd say "Org", "Gnus", "YASnippet", etc. GregLucas
I actually disagree. E.g. Java could be a page describing the different Java capabilities of Emacs, with links to the different JavaScript modes. This is especially true for JavaScript, where the js-mode shipped with the latest Emacs is completely different from the other widely used js2-mode by Yegge. Damd 18:20, 25 March 2012 (EEST)
Hm, good point about disambiguation... I still like the idea of using "titles" vs "commands", though. E.g. a Java page describing the built-in support (Java Mode) and then linking to articles on related packages (JDEE, etc) and why you might consider them instead. GregLucas 19:32, 25 March 2012 (EEST)
How would we handle e.g. Haskell? Emacs doesn't ship with any Haskell mode as far as I know... damd 19:58, 25 March 2012 (EEST)
Not ship, but a haskell-mode definitely exists and is in use...--84.192.109.230 18:33, 11 January 2013 (EET)

Template for mode-with-github-source pages?

Can Wikimedia do page templates? I'm sure the answer is yes. PhilHudson 23:07, 24 March 2012 (EET)

Issues

Syntax highlighting

Could we install a MediaWiki plugin which lets us do proper syntax highlighting of different languages? SyntaxHighlight GeSHi looks like a good alternative. damd 20:07, 25 March 2012 (EEST)

I've already installed it, but it doesn't seem to work properly (the fonts seem terribly small) and it doesn't support Emacs Lisp. Bozhidar 20:24, 26 March 2012 (EEST)
Are you sure the font size is not because of your web browser settings? They look just fine when I try it. About the Elisp support, we can still use just "lisp" until someone gets around to writing a version for Elisp. damd 18:44, 31 March 2012 (EEST)
I also found font size in the code snippets are inconveniently low. I dont have any special settings for my browser. I am on recent firefox. Kindahero 18:52, 31 March 2012 (EEST)
We could customize the CSS for the syntax highlighting plugin, but first let's make sure it's actually something in the CSS that causes this.
This is just an ordinary PRE element.
This is a PRE element generated by the syntax highlighting plugin.
Is the font in both examples too tiny? If so, I suggest you check your browser settings. You can configure this in the "Content" section of Firefox's settings. damd 19:13, 1 April 2012 (EEST)
I only find the second one small not the both. I started with 'firefox -safe-mode' still the same. It seems its general problem with Geshi see http://stackoverflow.com/questions/5354968/changing-the-font-size-of-code-formatted-by-syntaxhighlight-geshi-in-mediawiki Kindahero 20:25, 1 April 2012 (EEST)

fails to create thumbnails

I think some adminstative settings must be made in order to produce thumbnails of the pictures automatically. Can anyone do this .? check out Dictem to see what I am talking about. Kindahero 16:21, 31 March 2012 (EEST)

found this link, http://www.mediawiki.org/wiki/Manual:Configuration_settings#Thumbnail_settings Kindahero 16:24, 31 March 2012 (EEST)
another link, http://www.mwusers.com/forums/showthread.php?1334-Resized-thumbnail-images-not-displaying Feel free to delete these links Kindahero 16:28, 31 March 2012 (EEST)
I see that on [[File:Screenshot-dictem-buffer.jpg]], the main image is not displayed. The "Full resolution" link shows a valid image. By the way, this type of question might be appropriate for Google Groups:WikEmacs. Xophist 21:31, 1 April 2012 (EEST)

needed plugins

I had this problem when getting Cite_web set up on en.swpat.org. If I look into how I got it working, could it be fixed here too? Ciaran 15:31, 29 January 2013 (EET)

Closing down? But I just got here!

I just saw the Slashdot story about WikiEmacs closing down. Pity. A MediaWiki wiki about Emacs sounds great. I find MediaWiki sites much easier to navigate and I think they're easier to maintain/organise.

Maybe WikiEmacs' problem was just that it never got publicity? Ciaran 15:21, 29 January 2013 (EET)

I fully agree with Ciaran. I too am a newcomer. There are probably many more like me who would be willing to help out if only they knew this site existed. This wiki needs better publicity and cheerleading. We should have special event drives for porting and properly formatting content from the old Emacs wiki, in addition to ones promoting original article creation. A community needs to be established and articles need to be written. One way to get the word out is to contact administrators of various major Emacs projects and ask that they start an article on their project and add a link to WikEmacs in their helpful links section. If they do not want to help, no problem. However, I think many would, and it would let them know about the site's existence as a bonus so word of mouth would start to spread.
I find the style used on the old Emacs wiki to be horrendous to say the least. Is it an unstructured discussion forum? A knowledgebase of all things Emacs? A tips and tricks guide to hacking functionality that should be built into Emacs? Changing the tide of confusion on that site would likely be more trouble than it is worth. A new wiki is needed. I myself pledge to port over one article from the old Emacs wiki a week if that means this site will stay online. --Holocronweaver 17:37, 3 February 2013 (EET)
Take a look at this: BackwardKillLine on emacswiki. If just reading this article does not inspire you to to keep WikEmacs open, nothing will I'm afraid. --Holocronweaver 22:30, 22 February 2013 (EET)

WikEmacs staying open? Great!

Glad to hear it's not closing. Anything we (new contributors) should know? Is anything changing? Ciaran (talk) 09:51, 20 April 2013 (EDT)

Hello, I am the new caretaker of WikEmacs. No major changes have been made. This will continue to be a site by and for the users, so I welcome all input for suggested changes. As the site expands and users return, we will likely need to revisit the control structure and possibly modify the site rules. For now I would like to focus on growing the wiki. --Holocronweaver (talk) 15:09, 22 April 2013 (EDT)

Keeping the licence situation clear and clean

Just noting the current situation...

  • emacswiki.org is published under multiple licences, including GPLv2, GFDL (no version specified), CC-sa, and their own simple permissive licence.
  • The GNU Emacs manual is published under GFDLv1.3+
  • Existing WikEmacs texts are under GFDLv1.3+

For emacswiki.org, we could either ask them to specify their version(s) of GFDL, or we could use their text under their simple permissive licence. If we do the latter, we could include a mention of their copyright notice either in the default copyright notice at the bottom of all WikEmacs pages, or we could create a template "This page includes text from emacswiki.org, used under this licence".

For the GNU Emacs manual, if we're going to continue using GFDLv1.3+, then we don't have to do anything. But if we want to switch to the dual-licence model used by Wikipedia (and accepted by Stallman), then whenever we copy text from the manual, we'd have to put a template on those pages to say that those pages are only available under GFDLv1.3+ (and not CC-sa).

For text by WikEmacs contributors, we could continue to license it under GFDLv1.3+, or we could say that from now on, contributions are under the Wikipedia-style dual-licence (GFDLv1.3+ and CC-sa). This wouldn't change much but it would give us more options in the future if we do encounter problems.

I'll have to think for a while before having any recommendations, and there's currently nothing messy or problematic, but just wanted to note the situation early on in case anyone wants to make suggestions. I have experience with licensing issues. Ciaran (talk) 07:02, 23 April 2013 (EDT)

I have spent some time thinking on this, and your suggestion of asking emacswiki.org to clarify their version of GFDL appears to be simplest. That way WikEmacs could maintain its current GFDLv1.3+ license and no ugly licensing notices would be necessary when porting content from emacswiki.org, assuming thes choose GFDLv1.3+. In the event they choose a different version of GFDL, is it possible to port old versions of the license to new versions so we could use the material under GFDL1.3+? --Holocronweaver (talk) 13:30, 3 May 2013 (EDT)
Ok, I've thought through the scenarios now. The current Wikemacs licence notice is fine: if wikemacs contains original content plus emacswiki content plus GNU manual content plus Wikipedia content, it will always be true that the recipient can distribute under GFDL v1.3 or any later version. (emacswiki doesn't textually say "v1.3+" but all their pages are also under a do what you want, just preserve our copyright notice licence, so GFDL version ambiguities can be ignored.) So nothing has to be changed in the footer.
The two other issues are the copyright details, and the licence of original contributions.
Copyright details. If we include material from the manual/wikipedia/emacswiki, then we have to mention this somewhere (otherwise we'd be claiming to own stuff we copied from them). At a minimum, we have to put a general statement in WikEmacs:Copyrights to say "Some pages incorporate text from XYZ, received under <copy of their licence notice>".
Legally, that's all that's necessary. But, by lacking precision it leads to certain inconveniences. For example, if someone wants to copy an article from here that contains just original content, they should be able to include just a single line "copyright 2013 Wikemacs", but if there's no way to see that it's original content then that person will have to include all the "this may contain..." statements from WikEmacs:Copyrights. Or if there's a problem later (such as someone adding non-free content to emacswiki, and us copying it over), we're left with a mess not knowing what pages have to be checked/reverted.
(This reminds me that the copyright situation of my own wiki is not a shining example, but that's less problematic since all material is original content.)
So, for keeping track of copyrights, nothing is required and complexity just makes people less likely to do it, so it's just a matter of picking the low hanging fruit. I see four possibilities:
  1. Mention "from XYZ" in the edit summary. Drawback: if someone forgot to do this, there's no way to go back later and put it into the edit summary, and, the only way to search all edit summaries is by going to each page... tedious.
  2. Mention it on the page. This is what wikipedia does. Make a template so that editors can add {{copyright manual}} to the bottom of the page or in the "References" section to add one sentence "This page incorporates bla bla see WikEmacs:Copyrights".
  3. Same, but put it at the top of the Talk: page.
  4. Make a page for listing which pages contain substantial amounts of material from what sources.
The last two look nice and clean but that's also a drawback since if reader-contributors don't see how copyright info is noted, they won't realise that they should also make a note when they add third-party content to a page. The second solution adds a bit of mess to the page, but it works well with the wiki model of learn-by-copying.
If in doubt, I'd go with the second option. (Copying Wikipedia is usually a safe move.) We can always change at a later stage.
The last thing is the licence of new contributions (i.e. what should the notice under the edit box say "all contributions to WikEmacs are considered to be released under..."). My usual reflex is to use GNU whatever, but Stallman did give Wikipedia the green light to move to a dual GFDL + CC-by-sa for original contributions. I can't remember all the problems that motivated Wikipedia to migrate, but I think there were some issues like GFDL's requirement to include a copy of the licence when distributing covered works (so when you print a 2-page article, you have to add the 10 pages of the licence). Copying Wikipedia's approach probably has some practical advantages for people re-using Wikemacs material, and it allows people to copy material from Wikemacs into Wikipedia (while still being able to copy wikemacs material into the GNU manuals etc.). So for new contributions, a plain GFDLv1.3+ is fine, but the Wikipedia model is probably better. This wouldn't change the footer - GFDL would still be our primary licence since some pages would combine original content (GFDL+CC-by-sa) with content from the GNU manual (GFDL only) and the combination could only be distributed under GFDL, not CC-by-sa.
It would also be a good idea for the notice under the edit box to tell people "If you incorporate material from the GNU manual, please include {{copyright manual}} at the end of the page", and similar for emacswiki and Wikipedia.
Hope that helps. I'll be back at the end of June. None of this is urgent anyway. Ciaran (talk) 07:27, 3 June 2013 (EDT)

Which emacswiki.org topics to work on?

So, for each of the useful pages on emacswiki.org, we should make our own pages for those topics and incorporate the knowledge that's in the emacswiki.org pages, but how do we make a list of the useful emacswiki.org pages?

Does the site have any equivalents to MediaWiki's pages:

? (But IMO we should take a decision on the licence before doing a lot of work.) Ciaran (talk) 12:27, 24 April 2013 (EDT)

If not, I wonder if search engines could help us approximate the "value" of each page?
Hmm. I'd take that as a no. Looks like a random selection. Any other ideas?
Finding the pages with the most revisions shouldn't be too hard. Just involves a script downloading the history of each page and sorting by length. That might give an indication of the good pages.
The info on alexa.com isn't too solid, but gives some hints about what people look for. Ciaran (talk) 11:19, 3 June 2013 (EDT)
Retrieved from "https://wikemacs.org/index.php?title=Talk:Main_Page&oldid=4625"