Hello,
Today we've published a tender to implement the new TDF Membership
Committee’s web-based tooling:
Hello,
Hello,
Today we've published a tender to implement the new TDF Membership
Committee’s web-based tooling:
it's always funny to have a quick look on such tenders. I'd expect that
the DMS/CMS Plone could deliver about 90 % of the expected functionality
within it's core code or within an add-on. The accessibility, stability
and security also shouldn't be an issue.
(https://plone.org/accessibility-info). And it's OSS software.
Don't always reinvent the wheel, instead build your tooling on already
available great and stable software with little effort and small amount
of donation money..
Have a nice evening,
Andreas
Hi Andreas
I'd expect that the DMS/CMS Plone could deliver about 90 % of the
expected functionality within it's core code or within an add-on. The
accessibility, stability and security also shouldn't be an issue. (https://plone.org/accessibility-info). And it's OSS software.
So go on and feel free to make or arrange an offer covering /all/ the described use cases and further specified requirements. Python is labeled as preferred (because of [1]), not as required!
Concerning Plone as platform: I tend to prefer something with a slightly better bus factor [1] than our Plone experience has shown in the past. But also here: Insights welcome.
Hi Uwe, *,
Hi Andreas
I'd expect that the DMS/CMS Plone could deliver about 90 % of the
expected functionality within it's core code or within an add-on. The
accessibility, stability and security also shouldn't be an issue.
(https://plone.org/accessibility-info). And it's OSS software.So go on and feel free to make or arrange an offer covering /all/ the
described use cases and further specified requirements. Python is
labeled as preferred (because of [1]), not as required!
thus I'm not a freelancer and not owner of a company I'm not able to bid
on such a tender. I also not allowed to do such work within an
additional business.
Concerning Plone as platform: I tend to prefer something with a
slightly better bus factor [1] than our Plone experience has shown in
the past. But also here: Insights welcome.
Maybe it's most easy to complain on this. I offered hands-on workshops
with no interest from the TDF community in the past. The TDF admin team
got a training from a Plone core developer some time ago.
But there are other software with such Bus_factor in the project, but
nobody is complaining about that (or not loudly / in public).
Regards,
Andreas
Hi Andreas
So go on and...arrange
^^^^^^^^^^!!!
That's the point: Stop complaining but go on and nudge a company or a group of Plone developers to offer something and to give a credible answer how to ensure 5 years of reliable support on this. As a plone developer you'll surely know some.
With python we'll have no problem to find someone if we need some changes in a few years.
Maybe it's most easy to complain on this. I offered hands-on workshops
with no interest from the TDF community in the past. The TDF admin team
got a training from a Plone core developer some time ago.
...what doesn't change anything on the basic problem. We (in contrast to your opinion) did not first set up plone (or something else) and then look for people who perhaps maybe want to learn it (which - if we had found some - would have been at least the second best solution. But we didn't find them). We have to cut the coat according to our cloth. (btw.: Similar as the android app. Sad - but there seems no one out there interested to develop under TDFs umbrella)
But there are other software with such Bus_factor in the project, but
nobody is complaining about that (or not loudly / in public).
And what does this contribute to the discussion on the MC tooling? Please stay focused.
Hi Uwe, all,
Hi Andreas
So go on and...arrange
^^^^^^^^^^!!!
That's the point: Stop complaining but go on and nudge a company or a
group of Plone developers to offer something and to give a credible
answer how to ensure 5 years of reliable support on this. As a plone
developer you'll surely know some.
With python we'll have no problem to find someone if we need some
changes in a few years.
your reply showed little up to no knowledge and interest in that
CMS/DMS. Why should I bother /nudge Plone developers and ask them to
spent time on a proposal? Your response shows a very hostile tone
towards the Plone open source community.
(for your information: https://en.wikipedia.org/wiki/Plone_(software)
--> first stable release Feb. 2003, last major release July 2019, last
security patch: 2021/05/18)
(and for the records: I'm not a Plone developer, but developed Plone
add-ons)
Maybe it's most easy to complain on this. I offered hands-on workshops
with no interest from the TDF community in the past. The TDF admin team
got a training from a Plone core developer some time ago....what doesn't change anything on the basic problem. We (in contrast
to your opinion) did not first set up plone (or something else) and
then look for people who perhaps maybe want to learn it (which - if we
had found some - would have been at least the second
Maybe you have not been part of the crew that worked on the first steps
of the project and it's infrastructure. If individuals or small groups
wouldn't have set up a website based on Silverstripe (without asking for
permissions or without a poll) or a Template and Extension website based
on Plone, maybe the project would discuss have discussed about this
tooling for month without any visible action. One core principle of the
project is that the doers decide the way and you'll find this form of
action at many places in the project.
This principle will fail (for a volunteer project) once the people that
want to tell the doers what and how they had to work, becomes the
majority or the bosses.
best solution. But we didn't find them). We have to cut the coat
according to our cloth. (btw.: Similar as the android app. Sad - but
there seems no one out there interested to develop under TDFs umbrella)
Great picture with cutting the coat according to the cloth: it reminds
me on 'The Emperor's New Clothes'.
But there are other software with such Bus_factor in the project, but
nobody is complaining about that (or not loudly / in public).And what does this contribute to the discussion on the MC tooling?
Please stay focused.
Sorry Uwe but for years I was bantered by a core member of this project
for one mistake which I made in 2012. I never heard something else about
other software and volunteers in this project.
I did my work for TDF and LibreOffice only on volunteer state without
getting any payment or asking for such payment for years.
Regards,
Andreas
Hi Andreas
your reply showed little up to no knowledge and interest in that
CMS/DMS.
That's quite right. I'm really not interested in CMS/DMS (at least here) but in a sound and sustainable solution which eases the work of the MC. You may convince me any time, but I'm rather suspicious with proposals containing statements like "probably" or "90%" 
Why should I bother /nudge Plone developers and ask them to spent
time on a proposal? Your response shows a very hostile tone towards
the Plone open source community. ... (and for the records: I'm not a
Plone developer, but developed Plone add-ons)
And yes, I'm (here) not interested in the plone community. That's not the point at all: Here at TDf we're interested in LO and some related fields. That's our "core business" if you want. The necessary rest gets more or less outsourced if we can afford it. No one would expect TDF engages in i.e Gnucash community just to get it's bookkeeping managed. We instead would pay a gnucash ecosystem company to do the necessary coding, thus following our own credo on how open source software of a certain complexity can be sustainably supported.
So we look for a company to outsource a special problem solution, described in the specification document. And we are willing to pay those ecosystem companies for services we feel in need of but which we don't see as our core business (we strongly prefer companies engaged in open source community). i.e. a company which does the necessary plone adjustments. But we surely not would ask the plone community or a certain developer to do so on a voluntary base (c.f. "credo" above).
Maybe you have not been part of the crew that worked on the first
steps of the project and it's infrastructure. If individuals or small
groups wouldn't have set up a website based on Silverstripe (without
asking for permissions or without a poll) or a Template and Extension
website based on Plone, maybe the project would discuss have
discussed about this tooling for month without any visible action.
Right, it happened that I was in Nepal at the time TDF was founded
And all of this was surely true and necessary at the very start of the project when we didn't have the resources for other/better solutions.
One core principle of the project is that the doers decide the way
and you'll find this form of action at many places in the project.
This principle will fail (for a volunteer project) once the people
that want to tell the doers what and how they had to work, becomes
the majority or the bosses.
All right for the mentioned "core business" - or in other words: the goals of the foundation following our statutes. That's how a community works we believe. Besides: LO in no way is or ever was "volunteer project" (a project has a start and an end). It's a community with a high extent of volunteer engagement.
But this is in no way right if it comes to administrative decisions. To stay in the above example: It sounds rather silly to start a community wide discussion on which software we will use to do our bookkeeping. And in our case, the MC is "the doers". The tooling we use until today emerged exactly the way you described above: Someone set up something which was far way better than nothing. But it has some severe immanent drawbacks. And we understood that we don't have the skills to set up a solution by our own which satisfies our needs.
So we made a tender on this. Anyone who offers a sound solution is welcome. Within the boundaries of the specification and some abstract requirements like acceptable bus factor or serviceability.
Hi Uwe, all,
(...)
All right for the mentioned "core business" - or in other words: the goals of the foundation following our statutes. That's how a community works we believe. Besides: LO in no way is or ever was "volunteer project" (a
project has a start and an end). It's a community with a high extent of volunteer engagement.
But this is in no way right if it comes to administrative decisions. To
stay in the above example: It sounds rather silly to start a community wide discussion on which software we will use to do our bookkeeping. And in
our case, the MC is "the doers". The tooling we use until today emerged exactly the way you described above: Someone set up something which was far way better than nothing. But it has some severe immanent drawbacks. And
we understood that we don't have the skills to set up a solution by our own which satisfies our needs.
could you please explain who have and who should have access to the
membership data (old tooling and new tooling) please?
Has they / should the have access to all membership data from the start
of TDF up to now?
I found nothing about this in the detailed specifications for the tender.
Regards,
Andreas
Hi Uwe,
(...)
So we look for a company to outsource a special problem solution, described in the specification document. And we are willing to pay those ecosystem companies for services we feel in need of but which we don't see as
our core business (we strongly prefer companies engaged in open source community). i.e. a company which does the necessary plone adjustments. But we surely not would ask the plone community or a certain developer to do so on a voluntary base (c.f. "credo" above).
which leads me (after looking over the specifications in more detail) to
the question: what about the payment for drawing the specifications
paper? Is this done on a voluntary base like other public available
documents / tender specifications in the project?
Regards,
Andreas
Hello,
Hello,
Today we've published a tender to implement the new TDF Membership
Committee’s web-based tooling:
interesting to read in the specifications document about a self hosted
Captcha but without pointing to an example for such solution. If such a
solution (especially published within an OSS license) already exists,
why is it not already used within the current application form?:
https://www.documentfoundation.org/governance/members/application/
I'm curious about a working self hosted Captcha provider.
Regards,
Andreas
HI
what about the payment for drawing the specifications
paper? Is this done on a voluntary base like other public available
documents / tender specifications in the project?
Yes. It was done by me on a voluntary base.
Hi Andreas
could you please explain who have and who should have access to the membership data (old tooling and new tooling) please...I found nothing
about this in the detailed specifications for the tender.
First of all: This tender is based on a software specification and not on a description of the working processes of the MC. The latter are just subject as far as it seems necessary to describe the needed software functionality.
And this list thread should hold on that tender. Feel free to open another thread for anything else.
You did nothing find on data access in the specs because you obviously read only some few pages. In short: Regulating data access is not a function of the tendered software but in fact a function of granting access to it by our SSO solution. You find that described at page 14 of the specs - including the information who is intended to be able to access the software and thereby the data.
Hi
Interesting to read in the specifications document about a self hosted
Captcha but without pointing to an example for such solution.
You embezzled the "i.e." just before that. It was meant to illustrate the idea, not to describe or define a specific intended solution.
I'm curious about a working self hosted Captcha provider.
Me too
You want “e.g.” then not “i.e.”. The latter isn't a replacement for
“for instance”, it stands for “id est” (“that *is*”).
https://en.wikipedia.org/wiki/List_of_Latin_phrases_(E)#e.g.
https://en.wikipedia.org/wiki/List_of_Latin_phrases_(I)#id_est
Hello Guilhem
You want “e.g.” then not “i.e.”. The latter isn't a replacement for
“for instance”, it stands for “id est” (“that *is*”).
https://en.wikipedia.org/wiki/List_of_Latin_phrases_(E)#e.g.
https://en.wikipedia.org/wiki/List_of_Latin_phrases_(I)#id_est
Thanks for the hint. I use(d) it as abbreviation for "in example" - but indeed, for the better educated of us it surely is misleading
So indeed, it was meant as an example to illustrate something, not to emphasize something. I'll correct the specs accordingly.
Hi,
Hi
Interesting to read in the specifications document about a self hosted
Captcha but without pointing to an example for such solution.You embezzled the "i.e." just before that. It was meant to illustrate
the idea, not to describe or define a specific intended solution.I'm curious about a working self hosted Captcha provider.
Me too
would be great, if someone could shed some light on this. Is there
already a captcha provider available which could be self hosted. I
searched for such option, but with no result.
If there are nothing available yet, it is necessary to look for a
working solution / a captcha provider, which should be included into the
forms (in accordance with the GDPR).
Regards,
Andreas
Hi Uwe, all,
Hi Andreas
could you please explain who have and who should have access to the
membership data (old tooling and new tooling) please...I found nothing
about this in the detailed specifications for the tender.First of all: This tender is based on a software specification and not
on a description of the working processes of the MC. The latter are
just subject as far as it seems necessary to describe the needed
software functionality.And this list thread should hold on that tender. Feel free to open
another thread for anything else.
I already opened a new thread. I changed the subject of this thread (in
accordance to the usual way I know for mailing lists).
You did nothing find on data access in the specs because you obviously
read only some few pages. In short: Regulating data access is not a
function of the tendered software but in fact a function of granting
access to it by our SSO solution. You find that described at page 14
of the specs - including the information who is intended to be able to
access the software and thereby the data.
OK, got it now.
Have you already compared the details of meetings and decision making
for the board and the MC in the statutes. There are differences which
need to be considered for the access and the processing of the personal
data (of members and applicants).
Regards,
Andreas
Hi Andreas
I already opened a new thread. I changed the subject of this thread (in
accordance to the usual way I know for mailing lists).
No, technically you didn't
Just changing the subject isn't enough, because mail readers use the message ID of the mail you answered to thread mails (at least Thunderbird does) which will be written into the mail header when answering an existing mail. And you answered an existing mail which will keep your answer in the tread instead of opening a new one, despite of the subject's text. This will only used by some mail readers if the ID of the mail answered isn't available.
To be sure to open a new thread you have to write a brand new mail instead of clicking an "answer" button.
Hi Andreas
Have you already compared the details of meetings and decision making
for the board and the MC in the statutes. There are differences which
need to be considered for the access and the processing of the personal
data (of members and applicants).
You may save me a lot of time and work accomplishing this, giving also the sources.
Personally I can't see regulations for data processing in our statutes e.g. But besides this, German law provides a lot of special rights to information for members of an association like TDF. But this does not touch the way the tendered software shall work.
Hello Andreas,
would be great, if someone could shed some light on this. Is there
already a captcha provider available which could be self hosted. I
searched for such option, but with no result.
we looked at some in the past (don't remember their names from the top of my head), but the results were only mediocre. What helped us years ago in the wiki was to ask concrete questions eg. about TDF (Where are we located etc.), because these cannot be automated so easily, but still, you need to rotate these frequently... indeed, time for a proper solution to this.
Florian