emacswiki GSOC

emacswiki GSOC

[Nic Ferrier]

Someone approached me on the emacs channel to ask whether they could
help with the project to move the emacswiki to an elisp codebase.

Some of you will be familiar with this project. We're using elnode and
elwikicreole to build something that does everything that the current
emacswiki does.

I considered applying to do GSOC but I really didn't have the time to
work out what I did and didn't have to do.

The guy who approached me asked if he could work on the emacswiki stuff
under the GNU project or under the Emacs project (which have got GSOC
approval I think).

I'm presuming this is not possible... but can someone confirm for me?

emacswiki GSOC

[Stephen J. Turnbull]

Nic Ferrier writes:

 > The guy who approached me asked if he could work on the emacswiki stuff
 > under the GNU project or under the Emacs project (which have got GSOC
 > approval I think).

Emacs is not a GSoC org, and it has no visible presence in a quick
look at the ideas page.  Hard to see how Emacs is not going to get
slots if it wants them, though.

 > I'm presuming this is not possible... but can someone confirm for me?

By whose rules?  I see no reason why Google would have a problem with
it, as long as you're talking about coding.  One-off scripts to move
emacswiki content to the new elwiki wouldn't cut it, I'm afraid[1],
but code for the wiki itself, or a special version of Emacs
performance-tuned for wiki use would be OK.

If you're thinking about deadlines, well, lack of time and lack of
explicit contact with the community (especially the GNU org and Emacs
suborg admins -- Emacs is not a GSoC org) will (should?) hurt a lot,
but he's still got almost 3 days, I think.

But you need mentors who need to be accepted by the GNU GSoC org,
that's the big hurdle.  I think mentors can still register, but
jumping in at the last minute this way, if I were the org admin, well,
*I* would say it better be a blockbuster project and superman mentors.

I'm not authoritative for Google or GNU.  But if you've got the
mentors I don't see how it could hurt to ask.

Footnotes: 
[1]  But note that GNU Mailman does have a project for a *robust* set
of scripts which *will* be a permanent part of Mailman 3, to move
Mailman 2.1 lists to the very different Mailman 3 format.

Re: emacswiki GSOC

[Bastien]

Hi Nic,

Nic Ferrier <nferrier@ferrier.me.uk> writes:

> I'm presuming this is not possible... but can someone confirm for
> me?

I guess this is not possible too, because it does not seem to be a
programming project.  GSoC is about programming.

For a definitive answer, you should ask summer-of-code@gnu.org.

-- 
 Bastien

Re: emacswiki GSOC

[Glenn Morris]

Bastien wrote:

> For a definitive answer, you should ask summer-of-code@gnu.org.

Well first I'd ask the GNU project, since what is being talked about is
not a GNU project. Why would they want to use one of their GSoC slots on
it, especially when there are already more far relevant (IMO) proposals
for Emacs:

http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00602.html
http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00575.html

I really don't see this working in the time available:

http://www.gnu.org/help/evaluation.html

If the question for this list was: would you like a wiki server
distributed as part of Emacs, then IMO, sorry, no.

Re: emacswiki GSOC

[Aurélien Aptel]

On Mon, Apr 29, 2013 at 6:01 PM, Glenn Morris <rgm@gnu.org> wrote:
> it, especially when there are already more far relevant (IMO) proposals
> for Emacs:

But you need a mentor. Since no one has contacted me for mentoring me
I can't submit a proposal. I've switched to a different GSoC
organisation/project.

Re: emacswiki GSOC

[Glenn Morris]

Aurélien Aptel wrote:

> But you need a mentor. Since no one has contacted me for mentoring me
> I can't submit a proposal. I've switched to a different GSoC
> organisation/project.

I'm sorry that we let you down. I hope that you have a productive/fun
time with the other project.

Re: emacswiki GSOC

[Nic Ferrier]

Glenn Morris <rgm@gnu.org> writes:

> Aurélien Aptel wrote:
>
>> But you need a mentor. Since no one has contacted me for mentoring me
>> I can't submit a proposal. I've switched to a different GSoC
>> organisation/project.
>
> I'm sorry that we let you down. I hope that you have a productive/fun
> time with the other project.

I could have mentored probably.

It all feels a bit disorganized and opaque from my perspective.


Nic

Re: emacswiki GSOC

[Xue Fuqiao]

On Tue, Apr 30, 2013 at 2:42 AM, Aurélien Aptel
<aurelien.aptel+emacs@gmail.com> wrote:

> But you need a mentor. Since no one has contacted me for mentoring me
> I can't submit a proposal. I've switched to a different GSoC
> organisation/project.

Me too.  I sent an email to Stefan several days ago, but there is no
reply.  So I've switched to a different GSoC project (but under the same
organization, GNU), sorry.

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Modularization project (was: emacswiki GSOC)

[Christopher Schmidt]

Xue Fuqiao <xfq.free@gmail.com> writes:
> On Tue, Apr 30, 2013 at 2:42 AM, Aurélien Aptel
> <aurelien.aptel+emacs@gmail.com> wrote:
>
>> But you need a mentor. Since no one has contacted me for mentoring me
>> I can't submit a proposal. I've switched to a different GSoC
>> organisation/project.
>
> Me too.  I sent an email to Stefan several days ago, but there is no
> reply.  So I've switched to a different GSoC project (but under the
> same organization, GNU), sorry.

There is no entitlement to Stefan that he must do all the boring work.


I have been rambling about using package.el for the core a few
times already.

    http://article.gmane.org/gmane.emacs.help/90444

I follow lots of open source projects and participated in the SoC in
2009.  From what I can tell, only a tiny fraction of what is developed
throughout the summer by students actually makes it in the release
tarballs.  Most projects are overambitious, students do not stay with
the project after funding ends and, well, one just does not simply walk
into an open source project and revamp its inner core.  It does not work
that way.

Having that said, using package.el to rejuvenate all non-essential,
inbuilt packages sounds like a great SoC project.  There are no user
visible changes and it does not touch the C-side, either.  If this works
out, the result may build the foundation of a more accessible
distribution that works around lots of problems that have occured in the
past.[1]  This project helps users and developers alike.

What do you think of this project?

I realise this is rather late.  Is there anyone willing to work on this,
either as a mentor or as a student?  I could step in as a student.  As I
have already participated in the past, I would happily leave the honours
to someone else, though.

        Christopher

[1] What's avoided, right out of the top of my head:
- Security issues by external packages (CEDET)
- Giant, unreviewed merges a few days before the merge window closes
  (Org-Mode)
- People reporting critical bugs that have been fixed month ago
This does not include the numerous advantages of rolling releases, of
course.

Re: emacswiki GSOC

[Glenn Morris]

I'm sorry if anyone feels lets down.
I hope you all understand that everyone is contributing here as a
volunteer, and sometimes, for whatever reason, Something Comes Up, and
we need to take a break from Emacs-related mails (of which there are a
lot!) for a week, or longer.

It was earlier mentioned that mentoring people does not take too much
time - about 5 hours a week. I actually think this is quite a lot of time!
I should guess that the number of people able to commit 5+ hours a week
on a regular basis to working on Emacs is really small.

Personally I feel that teaching people is a significant responsibility
that requires a lot of effort to do right. I feel uncomfortable making a
formal commitment to do so. I can't even keep up with all the stuff that
people submit already.

http://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors
mentions having two mentors per student, and "it is also a good idea to
have a spare mentor or two", and "it is important to ensure that your
whole project community are on board with the mentoring task".
This seems like sound advice to me, but it also feels like something
that requires significant effort to do right.

I think the lesson for next year is that these issues should start to be
looked at a lot further in advance of the deadline.