Talk:Main Page

From WikEmacs
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)


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)
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)

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)
I will look into this. In the mean time, I would edit articles whenever you cannot you find the information you want on the wiki. This is how I edit wikis in general. --Holocronweaver (talk) 22:07, 26 November 2013 (EST)

1-844-494-0181| Email AT&T Support|AT&T Customer Support Number|AT&T Support USA|Support for AT&T

1-844-494-0181| Email AT&T Support, AT&T Email is free email easy to access by your phone that is iPhone, Ipad, Android. If you want to get AT&T Email account or you are existing AT&T Email members need online help for some problems occur in AT&T Email account such as AT&T Email account configuration on Iphone, Ipad, Android AT&T Email access issues on Google Chrome, Mozilla Firefox, Internet Explorer, Safari browser, etc. AT&T Email account sign in , sign up issues AT&T Email password recovery and reset help AT&T Email not sending or receiving emails AT&T Email attachment uploads and downloads error issues AT&T Email account activation and deactivation and so on 1-844-494-0181(Toll Free) AT&T Email customer service phone number is best for all worries, here its easy to find top AT&T Email email customer care support online help. This provide a team of leading experts who have long experience and proficient in handles these issues, provide best AT&T Email technical support number usa, complete care AT&T Email issues by live technical assistance AT&T Email customer service phone number usa, contact immediately to AT&T Email support and get easy solution. Contact Number: AT&T Email customer care support 1-844-494-0181(Toll Free) AT&T Email Customer Service Phone Number Call 1-844-494-0181 for the best deal on AT&T Internet, U-verse, and phone services in Hialeah, FL. Don't put up with cable any more, make the switch to AT&T Call 1-844-494-0181 for AT&T High-Speed Internet in Hialeah, FL. Stop paying too much for slow internet in Hialeah, get the best deal on AT&T right here. Find At&t at 5644 NW 167th St, Hialeah, FL. Call them at (305) 622-6300. May 5, 2011 1 Review of AT&T Device Support Center "This is supposedly the "creme de la creme" of AT&T Technical Support, and the only alternative to AT&T in Hialeah, FL -- Map, Phone Number, Reviews, Photos and Video Profile for Hialeah AT&T. AT&T appears in: Wireless Communications, Cell Phones, AT&T is a leader in telecommunication services, including cell phones, wireless, U-verse, digital TV, high speed internet, DSL, home phone, and bundled Jobs 1 - 10 of 28 28 AT&T Retail Bilingual Jobs available in Hialeah, FL on Indeed.com. one search. all jobs. AT&T Hialeah FL Locations, Enter Your ZipCode To Find AT&T Locations Along With Phone Number and Map with Driving Directions. Phone Companies. Call 1-844-494-0181 for AT&T U-verse in Hialeah and get killer deals on the most advanced TV & internet service available in Hialeah, FL. AT&T in Hialeah, Florida 33014: store location & hours, services, services hours, map, driving directions and more. Authorized Reseller

Retrieved from "https://wikemacs.org/index.php?title=Talk:Main_Page&oldid=47489"