Perl Monks

[mdk]

The nice guys at Evozon have been sprucing css files for Perl sites. Here is their idea for Perl Monks - this is just css changes so trivial to implement - who do we contact to get this done? (I'M LOOKING AT LEO INTENTLY).

[Leo Lapworth]

I've never had anything to do with PerlMonks - don't even know who runs it.

Leo

[sawyer x]

It's very nice except for two things:

- The orange there is kind of weird, since everything else is colorless.

- The pictures of people to the right look horrible. They looked horrible before, but now with a clean and beautiful design they pretty much jab your eye there.

[Dave Cross]

There's a group called "gods" on Perl Monks that contains the super-users. That might be a good place to start.

See http://www.perlmonks.org/?node=gods

Dave...

On 27 June 2013 09:38, mdk <mark.k...@gmail.com> wrote:

The nice guys at Evozon have been sprucing css files for Perl sites. Here is their idea for Perl Monks - this is just css changes so trivial to implement - who do we contact to get this done? (I'M LOOKING AT LEO INTENTLY).

--
Dave Cross :: da...@dave.org.uk
http://dave.org.uk/
@davorg

[Daniel Wright]

I am the PerlMonks liaison to pair Networks. I'm pretty sure that Tye is the person we'd want to talk to about this.

If I remember correctly, Perlmonks is one of those sites where you can choose one of several skins once you are already logged in.

There was recently a minor debacle over deciding if PerlMonks is a TPF site or not. The answer is: Yes, Perlmonks is owned by TPF, but the people on that site enjoy their independence, so we try not to meddle in the things they do. So, I suggest handling this with a high degree of tact.

-Dan

On Jun 27, 2013, at 4:38 AM, mdk <mark.k...@gmail.com> wrote:

> The nice guys at Evozon have been sprucing css files for Perl sites. Here is their idea for Perl Monks - this is just css changes so trivial to implement - who do we contact to get this done? (I'M LOOKING AT LEO INTENTLY).
>
>
>

> <perlmonks.jpg>

[Jess Robinson]

I'm a perlmonks dev (unless they revoked it), and James is a God... Will
have a look.

Jess

[Adam Dutko]

There was recently a minor debacle over deciding if PerlMonks is a TPF site or not.    The answer is:  Yes, Perlmonks is owned by TPF, but the people on that site enjoy their independence, so we try not to meddle in the things they do.    So, I suggest handling this with a high degree of tact.

Seems like the reply I sent through my phone didn't post. Weird.

Does that splash cold water on the idea of trying to style sites "owned/operated" by TPF in a similar way? I hate to use the word "branding" but it would seem to fit. 

[Jess Robinson]

Having actually looked at the image now.. Orange, ugh, was it done by
acme?? They've managed to lose the main title of the current section, that
should probably be put back, It would also be handy if they looked at more
than just the front page.

Perlmonks is built entirely of tables, so I'm not sure how trivial it is.
It does have "themes", which apparently can contain CSS, and there are
settings to make the main sections / sidebar items into divs, I'm not sure
if that makes it possible to move the nav links from the top to the left
side though, will have to have more of a think.

Jess

[sawyer x]

Mark, did these comments reach the designers?
The recent email with mockups didn't show any change in this regard.

[Adam M. Dutko]

I had a nice chat with a few folks at PPW this weekend.

I think it would be nice to see if we could get the sites migrated to a flat setup of js,css and html files before adjusting the design. Do you think that would make sense?

I've managed to pull just about everything down from www.perlfoundation.org and pushed it to a vps running Apache. I understand we will need to accommodate other important items like those found behind the "login page" (meeting minutes and etc.). 

With that said, I believe I've made good progress on two fronts:

1) Pull the content of the existing sites down and server them through Apache. 

2) Mockup what a markdown version would look like and get it running with nginx and a few other items.

With all that said, what did the marketing group have in mind as an "end product?" Do you want another wiki like setup? a WYSIWYG editor? a custom solution? a flat solution with some scripts to make it easier for non-technical folk to push changes?

Also, does it make sense to take a structured piece-meal approach:

1) Pull down content.

2) Publish new content in a flat format (html, css, js).

3) Identify a maintainable "dynamic" solution for non-technical folks to maintain.

4) Update the flat site with the new format/design.

5) Push the updated version into the dynamic option.

I look forward to the feedback.

Thank you,

Adam

[Adam M. Dutko]

Anyone? Buehler?

[Leo Lapworth]

Hi Adam,

I was leaving to others to reply, but my take would be...

JFDI (in the nices possible way) - no point trying to project manage something
as simple as this.

My 'vision' (no laughing at the back please) was a set of markdown
files that could be edited (via the edit button in github or obviously
cloned) with the main content and then served through
https://metacpan.org/module/Plack::App::Directory::Markdown with a
custom template - I actually set this up today at work for our
internal documentation and it works really nicely.

There process to this is:

1) get existing content
2) convert to markdown
3) publish
4) leave any other features to be requested/implemented later

Hope that helps, if you are getting stuck let me know and I'll knock
something together.

Cheers

Leo

[Daniel Wright]

I already had my personal say at PPW.    But just to reiterate for everybody else:

1.  While wearing my "pair Networks" hat, I'll say that we'll do our best to support whatever you want to do.

2.  While wearing my "TPF Board Member" hat, my personal preference would be a WYSIWYG environment.     The ideal in my mind would be using Movable Type.   We need as few barriers to communicating as possible.    Forcing people to go through github to make a change to a website would be a fail, in my opinion.

3.  Most important is getting something done.   So, if everybody disagrees with my #2, I'm not going to cry over it that much.

-Dan

[Adam M. Dutko]

Thank you for your reply.

> JFDI (in the nices possible way) - no point trying to project manage something

> as simple as this.

I agree. Which is why I stated in my original e-mail that I have two solutions running on my own VPS. 

The first is the flat solution (markup, minimal js and some styles) without the important "backend stuff" like meeting minutes and other "administrative items" hidden (not so well) from the outside world. These things still need to be pulled in but I don't have a login nor a good idea of what we need and don't need. 

The other is a version leveraging Plack::App::Directory::Markdown, nginx and varnish. It's incomplete because I'm wondering how we want to structure includes and other items so it makes sense to non-technical people how to update the site. Not everyone uses version control or Git (this isn't meant to be flame bait). We'll end up coming up with some implicit hiearchary I suspect. Would we then leverage HTTP Auth (gag) or some other mechanism to protect certain site content with our markdown solution? What did you have in mind?

Provided the above are easy to fix, I see two big items left to "tackle" before we can discuss testing:

1) We'll need a DNS record for testing ... maybe test.perlfoundation.org ... to point to the pair VPS. I realize we can have folks change hosts or other things but let's make it easy to switch back and forth. We can also use this for site design changes in the future.

2) We'll need to figure out how to properly structure the site, the includes and directories so adding front-page posts and other important site pieces works with the Markdown proposal. We'll then need to make sure we have an "easy button" for the marketing and designer folks to push so they push their changes to the site (and revert if need be) without having to be Git savvy. I have a Jenkins instance which does this for the flat site but that is yet another infrastructure piece I'd personally rather not have in the mix.

Leo...others...thoughts?

Thank you,

Adam

[Adam M. Dutko]

> personal say at PPW.

Yes. Thank you for talking to me. The reason I sent the e-mail is we didn't seem to get a chance to discuss with other folks and I wanted to make sure everyone was aware.

I too would like to see a WYSIWYG environment. With my limited knowledge of our current situation it would seem the previous environment has deteriorated and would prove difficult to patch. This is my main point of contention with using a tool like MT. Does Pair offer an image we can easily upgrade with each new version or would we have to have someone on point for patching?

Continuing with the WYSIWYG thought ... are there other options that are maybe written in Perl that we could use to host the site? 

> Most important is getting something done

I agree, which is why I do have something running. It seems we have three preferences:

1) Flat site + some auth mechanism + some RCS

2) Markdown + some auth mechanism + some RCS

3) WYSIWYG environment

I have #1 and #2 working but not all content is migrated and the authentication mechanism is still up in the air. #3 I'm fine with but will need a login to dump old content and import into the new MT site if that's what we want to use.

Thank you,

Adam

[Adam M. Dutko]

> http://www.pair.com/services/pairsim/

I like.

> Karen Pauley had mentioned that she knew some people at MovableType that had expressed an 

> interest in helping out TPF. 

I do recall hearing something to this effect. I think she was going to reach out to them after PPW. 

Thank you,

Adam

On Mon, Oct 14, 2013 at 8:15 PM, Daniel Wright <d...@dwright.org> wrote:

On Oct 14, 2013, at 7:38 PM, Adam M. Dutko <dutko...@gmail.com> wrote:

I too would like to see a WYSIWYG environment. With my limited knowledge of our current situation it would seem the previous environment has deteriorated and would prove difficult to patch. This is my main point of contention with using a tool like MT. Does Pair offer an image we can easily upgrade with each new version or would we have to have someone on point for patching?

pair has a package management tool called the pairSIM that will automatically install MT and do version upgrades for us:

http://www.pair.com/services/pairsim/

Continuing with the WYSIWYG thought ... are there other options that are maybe written in Perl that we could use to host the site? 

The only other option that I can think of would be Drupal, but I'd rather avoid Drupal.   It has all the power and flexibility of WordPress with absolutely none of the user-friendliness.     

> Most important is getting something done

I agree, which is why I do have something running. It seems we have three preferences:

1) Flat site + some auth mechanism + some RCS

2) Markdown + some auth mechanism + some RCS

3) WYSIWYG environment

I have #1 and #2 working but not all content is migrated and the authentication mechanism is still up in the air. #3 I'm fine with but will need a login to dump old content and import into the new MT site if that's what we want to use.

By the way, Karen Pauley had mentioned that she knew some people at MovableType that had expressed an interest in helping out TPF.   Perhaps we could get them to build us a MT template using the new design?

-Dan

[Karen Pauley]

On 15 October 2013 09:30, Adam M. Dutko <dutko...@gmail.com> wrote:

>> Karen Pauley had mentioned that she knew some people at MovableType that
>> had expressed an
>> interest in helping out TPF.
>
> I do recall hearing something to this effect. I think she was going to reach
> out to them after PPW.

We have been speaking to Moveable Type recently about getting licenses
for MT 6. I'll let you know what the outcome is. I believe though
that we will be starting first of all with upgrading our blog that
lives on news.perlfoundation.org as we are having quite a few problems
with that.

All the best,

Karen

[Ovid]

Hi all,

Evozon has been in discussion with the blogs.perl.org group about porting blogs.perl.org to Perlbee. The discussions haven't stalled, per se, so much as I find myself prodding some folks from time to time. This email from Karen is effectively a prod to me and I'll return to that discussion with the blog folk.

The core issue with MT is simple: it's an unmaintainable mess. And even without my admin access, I could do some "interesting" things with MT that people wouldn't like.

Perlbee is smaller, more sane (for some definitions of sane), and available on github and Evozon has committed to making the transition for us if we can coordinate this. For a single-user MT setup, it should be even easier. Plus, there are no license costs.

If this sounds like a win, let me know who I should put the Evozon people in touch with and see if we can make this happen. They've previously moved their blog from MT to Perlbee and want more experience in this area. It seems like a win-win situation to me.

I know the MovableType folks have good intentions, but their past track record hasn't been inspiring.

 

Cheers,

Ovid

--
IT consulting, training, international recruiting
       http://www.allaroundtheworld.fr/.
Buy my book! - http://bit.ly/beginning_perl
Live and work overseas - http://www.overseas-exile.com/

[sawyer x]

I don't know enough about MT5/MT6, but Perlbee is basically a Dancer app, which means it's PSGI. We can adapt it to every situation, add our middlewares, use any web server, mount additional apps under different paths, if we want, and so on.

From the Dancer side, we'll be able to tackle any possible problem Perlbee might have with the framework.

So overall, we have a lot of flexibility there.

[dutko...@gmail.com]

It’s nice to read this item is coming back to life.

I’d love to work on this again and help see it through …

-Adam