Re: GNUstep SoftWare Index - new project home and sources of the tool

[Banlu Kemiyatorn]

On Sun, Jan 9, 2011 at 12:29 AM, Ivan Vučica <ivucica@gmail.com> wrote:
>
>
> 2011/1/8 Banlu Kemiyatorn <object@gmail.com>
>>
>> And you cannot automatically have that with a dedicated tool,
>
> Sure you can. You have a systematized input method, and systematized
> presentation method. More importantly, you have an organized data structure
> that you can datamine (e.g. show "most active projects", "most recently
> updated projects" without manually updating the wiki page).
>
>>
>> ie. you cannot do that without a plan.
>
> Sure. Sketch out what properties are necessary before designing relational
> database and presentation. For example, I did that in my previous email.

The second part was the summary of the first one. You shouldn't
logically be able to agree to one and not to another.

What does most update or active projects mean? Active commits? Just
use a php bot triggered by cron to query necessary log from repository
or just link ohloh or just the cron update it to anything through bot
API.

>
>>
>> You will need a plan for backup,
>
> I'm not sure what do you mean here -- you need the same with wikis. History
> != backup.

You can dump the recent changed Wiki sources by any one. I wasn't
talking about history.

>
>>
>> corrections and ways for the others to get backup your data and source
>> code of the web software in case that your system went down.
>
> What's the big deal about making nightly dumps of the SQL, sans the user
> account data.

No big deal if you make it available publicly and documented and have
storage and integrity (if the database was designed to support
integrity records then this is not necessary)

>
>>
>> For both systems, what you need is documentations.
>
> Sure. But with dedicated, either web-based or desktop, software, you don't
> necessarily need to have separate documentation for simplest stuff. Like
> markup, or what content is required during input. You just need to present
> the fields and tell the user "these fields are required, this field means
> this, this field means that", et cetera.

As long as you sacrifice the flexibilities. But if that still cause a
lot of problem with anyone then just use a php bot to post it. Simple
enough and you still can track changes and can manually add extra
fields through the wiki interface w/o any dedicate log required in the
database.

>> I dont see it as a pain. For many people it is even much easier than
>> messing with SQL. What is so hard about adding or removing properties from a
>> template really? How is that harder than granting rights, checking docs that
>> define the tables, verified the value for possible web code injections etc.
>
> This one really depends on tastes. All I can say is I believe a dedicated
> database to be more systematic.
> Why don't wikis themselves use other wikis for storage?

Why do you want a wiki at all if you just want a storage?

>
>>
>> I am not against the SQL works in anyway. But I dont believe ther is an
>> ideal tool for anything. A database can do the job without a wiki and can
>> also even support the wiki process in many ways. The problem is the plan for
>> the maintenances I described. But if you have time and power to make it
>> works better then just do it.
>
> Maintenance is an issue with wikis as well; in both cases time and will is
> required.

Of course but if you actually follow the thread the point was clearly
made that we don't have to maintain the Wiki at all as it will be
maintained by people who aren't interested in GNUstep project, hence,
we will have more man power to actually work on GNUstep.

> Please do note that I'm looking at it this way: What will people find easier
> to use? What will guarantee that more people will use the system properly?
> What can have more consistent input and presentation without involvement of
> additional editors that constantly verify user input? What is more prone to
> spam?

Easier to use? I think it must be a wiki + php front ends since there
are more options available for different kind of usages.

If you just really want very consistent input and presentations like
the lunar module wouldn't land right w/o that. I agree with you.

No spam for both. One thing not really related to this but the SWI
keeps rejecting me submitting a new app because I didn't type the
human verification code correctly but I did.

>>
>> > where is
>> > the bot or the reviewer supposed to get that data from, or where is the
>> > bot or the reviewer supposed to place them if they don't fit into a
>> > template?
>>
>> In comments and post alert for needs review.
>
> So, more eyeballs is the solution? You're counting on people's eagerness to
> help. If more people were so eager to help, GNUstep would be much farther
> along the road to Cocoa compatibility (I don't know about OpenSTEP so I
> can't comment on that) than it currently is. It's already quite good -- but
> if people were eager to give up time and help, then it would be further
> along.

If you put one or two persons who should code or learn to code for
GNUstep to maintain a full features web app then there's even less
people to help with the actual product.

>
>>
>> And where do you want to place that with SQL? Just let them refill the
>> form sure. It's good in its way, but I dont see it better.
>
> Doing good user input sanitization and not letting user input too much (e.g.
> extra markup) means user will not be able to mess things up. Simply don't
> let user enter random comments outside the "Developer's commentary" field.
> Only description serves as project description. URLs go only in the URL
> list.
> Less cleanup is needed, need for cleanup is more easily recognizable, and
> you can more easily verify quality of user input. For example, you can
> reject "%)($"'$" as project title more easily if you have a custom form than
> otherwise. You can also more easily require that all projects submit a
> description that is at least 20 words long.

Clean up is just a matter of revert, but as I said that bot with front
end would do the job with extra benefits and possibly less code.

>
>>
>> And great less flexible.
>
> Precisely. Don't trust the user to enter consistent, high-quality data. At
> least check the data to make sure it's at least mediocre, if not
> high-quality.

I do trust Wiki People to certain level especially for the capability
to learn, to be obsessed and to get involved. I don't trust a system's
judgment as much. Note that I don't tell you to trust or not to trust
anything.

>
>>
>> Less flexible and need more security plan for community to access the
>> host. And if someone accidently break some records, you will need a complex
>> revision control method.
>
>
> You keep repeating the "less flexible" as if it is a bad thing in this case.
> It is not. Having a consistent, easily browsable list is preferable in case
> of software.

I don't think I say it is bad and I also don't say it is good as well.
What I tried to explain was that your solution wasn't better in all
scope.

> Please take a look at Apple's highly successful App Store. They don't have
> random categories. They don't allow you to enter unlimited amount of
> keywords. They don't let you add software that doesn't have at least one
> screenshot and more than five. Even that way sometimes you get spam -- but
> much less if the store were to allow you to enter random data, random
> markup, et cetera.
> Not only that, but this lack of flexibility has allowed Apple to present
> product pages in a platform-specific way in iTunes, on iPad, on iPhone/iPod,
> and even preview pages on the web: on each platform, the data is presented
> nicely, because each field can be formatted in a platform specific way.
> And I do not mean just formatted: I mean placed in various native controls
> (listboxes, etc).

And do they improve the quality of their users for their roles as a
good community members by doing that? Or just suck their money as
their customer are losing ability to realize the important of freedom
and how to maintain it?

> Using a wiki would mean never being able to produce an installer app that
> allows single-click installation of a piece of software (I'm thinking of a
> GUI for a MacPorts-like build system). That is, never being able to do that
> without transferring all the data into the new system that would actually be
> parseable by the system.

You meant "Using a wiki alone for everything"

> We can go on and on: you can tell me that everything can be done with a wiki
> (e.g. build spec file could be placed inside special tags on the wiki page
> or even just the build files being separately hosted, and the wiki could
> itself be browseable using something like embedded WebKit) -- but that's not
> the point.

I sure can tell you that everything can be done with a wiki but why
would I do that.

> Finally, I'd like to point out that I don't have the time to focus on any
> such project, nor did I check out what Dr. Schaller's SWI looks like. I've
> just put forth my opinions on how an "app repo" could be done, and why I
> don't think just putting things on a wiki is the perfect solution. My
> opinion is that any kind of a solution is better than none, so anyone
> embarking on this journey with any sort of a plan in mind has my best wishes
> for success :-)

It's good to make an opinion but it is not good to judge that I want
to do everything by a wiki based on only that I suggest to use it at
the core of the system and ignore a few points I made. So if I did
that please also let me know.

> --
> Regards,
>
> Ivan Vučica
>
>



-- 
    .----.     Banlu Kemiyatorn
  /.../\...\   漫画家
 |.../  \...|  http://qstx.blogspot.com (Free Software Advocacy & Development)
 |../    \..|  http://feedbat.blogspot.com (Studio Work For Hire)
  \/      \/   http://groundzerostudiocomplex.blogspot.com (Studio Research)