<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Good points, all. We definitely should have a requirements doc
rather than just dumping out code (that may or may not need to be
replaced later).<br>
<br>
I think we have a pretty good schema now, so key points in the
requirements that I think we need to nail down are:<br>
<br>
1) What functions does a user need to be able to perform? What
functions does an administrator need to perform?<br>
<br>
2) What does the UI look like? From a user perspective? From an
administrator perspective?<br>
<br>
3) How do we handle authentication? How do we handle authorization
(i.e., how do we keep track of who is an admin and who is not)?<br>
<br>
4) Do we try to integrate this into MediaWiki, or do it
standalone? (I'm personally a fan of the latter approach, as I
think it's more flexible, and doesn't put us at risk of being broken
by a future MediaWiki upgrade - even though it means, yeah, people
have to have Yet Another Username - but this is one of the reasons
we have been exploring the idea of setting up an LDAP directory,
which could be used to help solve the problems in item #3 above).<br>
<br>
I think the easiest way to proceed from here is to set up a GitHub
repository, and that way we can use the Issues system in GitHub to
track the open work (and who is doing it), and we can keep all that
traffic off this mailing list. It also opens up potential
participation to people who aren't on the mailing list.<br>
<br>
Alternatively, we could use something like Fossil, and tie it into a
system like TRAC (does TRAC have a Fossil plugin?) and host it
ourselves. But as distasteful as Git can be, I think there's more
"critical mass" in terms of people who are familiar with it. I'll
be happy to set up that repo (and we can start by putting the
requirements doc in there) if we want.<br>
<br>
--Pat.<br>
<br>
<div class="moz-cite-prefix">On 1/13/2015 11:26 AM, Joe Prostko
wrote:<br>
</div>
<blockquote
cite="mid:CAKfvZxyXaF4C4JhkXQGNevX6JbqKQzZFXz1OSbNSsRCGYPur4Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>On Mon, Jan 12, 2015 at 9:28 PM, John Lewis <<a
moz-do-not-send="true"
href="mailto:oflameo2@gmail.com">oflameo2@gmail.com</a>>
wrote:<br>
><br>
> Final warning!<br>
><br>
> If I don't see a line of PHP code posted to the
wplug-internet mailing<br>
> list by Wednesday, I will just start dumping code.<br>
<br>
</div>
<div>Maybe I simply missed out on all of this somehow, but
before I write a single line of code, I need to see a
requirements document or some such thing to see what the
scope of this is (even if I help write said document).
I've wasted too much time over the years as a developer
implementing something according to what I was told, and
then had to throw away a lot of code over and over as
the requirements changed. I don't have a ton of
patience for that nowadays, especially when it comes to
volunteer projects that are competing with time for my
day job and any freelance work I'm doing on weeknights
and weekends. I have no problem throwing away code that
I write that is "garbage", but I am less ecstatic when I
have to rewrite a ton of code due to me and the client
(or whomever) having different ideas of what all needs
implemented and how.<br>
<br>
Yes, it's a contact/membership database that needs
interacted with, but are we going the MediaWiki plugin
route, or is this all standalone outside of MediaWiki?
How do we plan on interfacing with Stripe and other
payment outlets? I remember Vance and Pat looking at a
page showing the schema as decided in the past and all
of that, so obviously there has been some work and
discussion done previously. Anyway, my point is I'd
prefer there being no room for interpretation since it
should be all explicitly laid out, and we just have this
all decided before the actual work begins. That is why
I didn't really give a ton of input on the schema layout
either, since I prefer doing work like that after the
requirements are stable.<br>
<br>
</div>
<div>Also, I don't see the value in posting code to a
mailing list. That should live in a code repository
somewhere where interested parties can see it and any
trusted developers can contribute to it. I don't mind
setting up a Fossil repository on our VPS, but if we'd
rather use Git/Hg/whatever on a service like Github or
Bitbucket (or hosted via something like Gitlab), I'm not
opposed to that either.<br>
</div>
<div><br>
</div>
If you want one line of code though, here you go. ;)<br>
<br>
</div>
<?php<br>
<br>
</div>
(Okay, I'm joking obviously, and I am glad you are trying to
keep this project moving. I don't know if using terms like
"Final warning!" are a good motivator though. Terms like that
tend not to motivate people doing work on a volunteer project,
where people work on what they want when they want when they
have time. That type of language certainly doesn't motivate
me anyway, quite honestly.)<br>
<br>
</div>
<div>Keep in mind everything I stated above is my opinion. If
you'd rather just start dumping in a bunch of code that may or
may not ever be used, feel free. I like to take a more
systematic approach though when given the choice so I don't
end up with an unmaintainable mess.<br>
</div>
<div><br>
</div>
- joe<br>
<div>
<div>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
wplug-internet mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wplug-internet@wplug.org">wplug-internet@wplug.org</a>
<a class="moz-txt-link-freetext" href="http://www.wplug.org/mailman/listinfo/wplug-internet">http://www.wplug.org/mailman/listinfo/wplug-internet</a>
</pre>
</blockquote>
<br>
</body>
</html>