Re: [Pyblosxom-devel] new site pushed

[will kahn-g. <wi...@bl...>]

On 03/19/2011 06:19 AM, Dieter Plaetinck wrote:
> On Fri, 18 Mar 2011 22:42:15 -0400
> will kahn-greene <wi...@bl...> wrote:
> 
> the links "report bug" / "request feature" point to the same. why not just one link "bugtracker"
> or maybe "bugs / tickets" but I think 'bugtracker' is clear to everyone that it also includes feature requests and/or misc tickets.

That makes a lot of sense.  Fixed!


>> 1. the features list on the front page -- are there other things we
>> should mention?  things we shouldn't mention?
> 
> * the last line basically repeats the 2nd point. imho remove it entirely.

You're right!  Fixed!


> * "works with blog standards" -> maybe mention this is done through templates so that people don't think the core has bloat for that built-in.

I'm going to be a bit hard here, but bear with me.  I think the "bloat"
word is overused and really means "the software has code for things I
don't use" which is true of all software for all people.  If people
think that of a file-based blogging system and it's a turn off, then
they're not the sort of people I want to deal with anyhow.  I'm pretty
ok with them not using PyBlosxom.  So there's that.

I think it's important that PyBlosxom works with blog standards, so I
think that should be in the list.  However, it really should include
feeds as well as some of the other standard blog things like pingbacks,
trackbacks and things like that.  PyBlosxom has plugins for those, but I
have no idea if they work anymore and even if they did, they should
probably get re-written to use 1.5 awesome-happy-goodness.  So while
this is in the list, I think we're actually kind of failing on this front.

I think I want to leave it for now, but recognize that this line is
debatable.

I'd also be interested in whether there are other blog standards that we
should be supporting.  What is PyBlosxom missing to interoperate better
with other blog systems?


>> 2. the quick start section on the front page -- it's slightly more
>> complicated than these steps, so I wasn't sure whether to include them
>> or not, but I really like the idea of having a quick start
> 
> instead of [ edit config.py ]
> you could put $ $EDITOR config.py

I thought about this for a while and I think I prefer the "[ edit
config.py ]" since it's a general instruction even though it doesn't fit
in with the other things which are shell commands.

I'm not sure it's true that all people have an $EDITOR environment
variable.  So I think changing it to "$EDITOR config.py" possibly makes
it applicable to fewer people.


>> 3. the "how to send us a patch" section on the development page -- do
>> those instructions look adequate?  how would you improve them?
> 
> * has a typo commet -> commit

Oops!  Fixed!


> * an alternative for patches is pushing commits to gitorious (or any other public git repository) and issuing a pull request (in the latter case, a pull request is basically a mail saying "please pull from that repo/branch")
> looks ok otherwise.

I really dislike the gitorious merge request thing.  I know you didn't
mention that, but I'll just put it out there.  It's entirely possible
I'd like it more if I could figure out how the damn thing works without
picking up all patches everywhere.

Pull requests are interesting, too, but they require that someone's
clone is in a public place that I can pull from.  I think just talking
about git format-patch is a lower common denominator, so I think I just
want to go with that.


>> 4. the navigation items in the sidebar -- is it saner than it was
>> before?  are there better names for some of the sections that we should use?
> 
> * you can put me on the pyblosxom users page. my blog is @
> http://dieter.plaetinck.be/

Added!


> * the section "documentation" with 2 subitems, one of them being "documentation" is a bit weird.
> maybe append the two links to the upmost list (i.e. add them below the link to bugtracker)

Done!


> * users and registries could get their own title. like "Community". then, under
>   community you could put also a link "Get in touch" which contains the mailing
>   list and irc info. that might be a better place then the home page for it.
>   imho the home page should be short and focused. (readable without scrolling) so if you can get the
>   irc/mailing list info away from there.. maybe also remove the "Bugs/Features" section. after all there are links to that from the main menu.

I put them in a Community section and added links for the two mailing
lists and IRC.  I have them link to the respective sections on the front
page.

One of the things I really want to do is bring together all the critical
bits of information someone needs to know.  So from the front page,
someone ought to be able to:

1. evaluate pyblosxom in regards to whether they should use it
2. find information about mailing lists and irc
3. download the software
4. get the source code
5. report bugs/features
6. contribute patches

Those are the critical actions that encompass the human side of the
project.  I want to experiment with putting all these things on the
front page rather than separate them out into a few different places.

I'm also not sure that the "readable without scrolling" rule is
compelling.  What's the motivation for that rule?

I would definitely be interested in project pages you find compelling as
well as what requirements you (or anyone else reading this email) think
a project front page should have.

/will