Hi Greg,
I am sorry that nobody else chimed in and that you were a little bit
dismissive on certain points. Let me bring them up again and rephrase them.
I think there are some valid ideas in Damianos an subsequent heated
discussion and I don't want to act unilaterally.
I worry that nothing will change. I know you're busy. I think
what's best is if we develop another site in parallel, independent of
the existing site.
I worry instead of a big remake or something similar, I am for
evolutionary changes. Any problem already addressed (e.g. naming issue)
can be of immediate benefit. Also one change can show the next path
under another light. Isn't that the base behind agile or small subprojects?
1) "Core Library" name. Possibly logo?
Also, need clarification. You already said you're against the logo
that includes the orca, but I am not sure that matters. It's actually
my preferred logo since it was something that was discussed a while back.
I specify: Damianos wanted to identify the project with its framework.
Now, if our project is "GNUstep" like confirmed in 2) I think we need a
specific way to name our core libraries.
Over the site we call things like "GNUstep Suite", "libraries", "core"
or "GNUstep" without further specification
I was thinking to a name for that. I'd stick with "GNUstep Core" to
base+gui+back, but we could also decide to add a catchy name.. akin
"cocoa". But most beans are already taken :)
As for a logo, I'd suggest something specific to "GNUstep Core" to make
it visually recongizable. I was not suggesting to use our mascot and
change the GNUstep logo of the project.
E.g a "folder" or a "library" with the GS logo. Or something else to
represent "core". It would be just of visual use in the website or wiki.
Then think if we want a name for the remaining other libraries
2) Project name
GNUstep. :) If you guys think it should be changed, fine, but I don't
think that would work.
Agree. We could have called it like "GNUstep.org", or a specific
capitalization... no problem. Let's just rename the library. It is my
preferred line.
So GNUstep + Logo standard remain for the project. No big deal. I too
prefer to maintain logo & name the same for the project.
3) "GNUstep name usage"
Sorry, I am not sure that the idea of how the GNUstep name will be
used ever came up or is in question. I do believe that WindowMaker is
a very large source of confusion. So, for clarification, what are you
referring to here?
I was not referring to WindowMaker, which is a source of confusion
because people are just lazy. Actually, it would be interesting to work
with them more again.
In this specific case, both sites state and even cross-link the
respective pages saying "we are not a windowmanager" and "we are not
GNUstep" :) I extra took care.
I was referring to projects, apps, desktops, distributions and other
things which use and refer to us with GNUstep.
Example: there exist(ed) the "GNUstep Live CD". They way it was labeled,
worded and distributed it appeared as an official CD and so the way
packages were chosen, styled, would "represent us". That is untrue and
can be misleading.
On the other hand, these initiatives do bring us exposure and are
interesting, so I do not want to suffocate them or start putting
legalese "waivers" like "not officially endorsed".
I hope I expressed the concern... share your thoughts.
4) relation to other Desktop environments and the way we "quote" them
and how they can quote GNUstep
Given that we are EXPLICITLY not a Desktop Environment, we should have
links to them.
We have a links to them, of course. Also they are or can be described in
the Wiki. I changed the Website so that they are not on the homepage and
are presented more or less "equally"..
But how can or should them refer to us? I see no issue e.g. with Etoile
or NEXTSPACE.
But GSDE, GNUstep Desktop Environment, could be... since it sounds
"official".
I don't want to start a war now, just raising the flag. E.g. we could
think of asking certain "requirements" or a different, name, I have no
idea, just want you guys (and Greg) to think about it.
I already have a couple of people on the discord (namely Ethan and
Damian) discussing documentation. You should join.
https://discord.gg/M2REKrD5
As expressed privately, I prefer not to use discord for FOSS activity,
it is discouraged and I agree. I no longer have an account on it.
I think for most topics it is good to have an archive, so email is good.
Also, with different timezones and working days, it may take some time
for people to reply. So I wait for some time to reply.
If there are no answers I will draw conclusions. Usually it can be
interpreted, "I'm fine, I don't care, go ahead".
TBH, I think the wiki needs to be reduced. Right now it is somewhat
redundant as some of the pages on the wiki have the same content as
the pages on the main website. The wiki should be reserved for
tutorials and other information.
I know that, it has a historical reason: lots of stuff was done on the
Wiki but not on the website. Then the Wiki went R/O.
The Wiki is a good collaborative place where also non-technical people
can contribute and generate content, which can be carried over to the
website (I did so several times). The Wiki then needs to be cleaned up
or minimized, we shall catch up on that activity and maybe define a
process to that. E.g. a section to review or "slated for removal".
Also there are some administrative issues, I'll contact you and Ivan
privately about that.
5) update and "describe" the library presentation (after 1) for obvious
reasons shown here:
https://www.gnustep.org/developers/map.html
I think that map still makes a lot of sense. Is there a way we can
generate some of this information as part of the documentation?
Not that I know, that content is more a "presentation" of the
architecture, not intrinsic in the classes.
That is exactly the kind of content we miss and need to enrich.
The map still makes a lot of sense, but do you agree that with some text
it would make it even more? With some text and references it would be a
great guide for developers.
7) Work with Richard on links to "unframe" frames of Reference
documentation and study a way to navigate it within the site. Just a
first step to clean this up.
One thing that might be interesting here is to make it possible for
autogsdoc to generate something other than HTML or to make it possible
for it to avoid using some of the older tags which are not addressable
by CSS.
I think we should have a work chain to generate a a PDF, so some people
can just download it and move around. Often more convenient.
A lot of ideas which are on my discussion plan with Richard, but major
work was done to actually generate correct pages (again!).
My attempts to style CSS failed miserably, I know others had more
success. I don't want to encumber offline versions, there are many pain
points in something apparently simple.
But one is: there are a lot of methods without description... so instead
of thinking of a "classy presentation" we should think also about the
content.
Riccardo
